commit 5ca2aa7ddcadb39c3fba92326ed4cb731134bff9 Author: Alexandre Frade Date: Sat Dec 12 23:17:43 2020 +0000 Linux 5.9.14-xanmod1-cachy Signed-off-by: Alexandre Frade commit de6a4443e19661849b7f23e44fb7c1eb1204f64c Merge: 5bede9ab8d94 991c8eb3ba99 Author: Alexandre Frade Date: Sat Dec 12 23:16:29 2020 +0000 Merge remote-tracking branch 'origin/5.9' into 5.9-cachy commit 991c8eb3ba99fcaaca95fc1dfc3a857bc1db3a6c Author: Alexandre Frade Date: Sat Dec 12 00:02:57 2020 +0000 Linux 5.9.14-xanmod1 Signed-off-by: Alexandre Frade commit 779cbc8eb181679cd5db635d61339c2bb36a7029 Merge: 4d5bf3938642 991a0920e1ac Author: Alexandre Frade Date: Fri Dec 11 23:50:55 2020 +0000 Merge tag 'v5.9.14' into 5.9 This is the 5.9.14 stable release commit 991a0920e1acc1244b81c4308407e6ac0c8e8bd9 Author: Greg Kroah-Hartman Date: Fri Dec 11 13:22:14 2020 +0100 Linux 5.9.14 Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Jeffrin Jose T Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20201210142606.074509102@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 0f8ad899df8c159d0ac293eb7aafeea3a536bd3a Author: Alexei Starovoitov Date: Tue Dec 8 19:01:51 2020 +0100 bpf: Fix propagation of 32-bit signed bounds from 64-bit bounds. commit b02709587ea3d699a608568ee8157d8db4fd8cae upstream. The 64-bit signed bounds should not affect 32-bit signed bounds unless the verifier knows that upper 32-bits are either all 1s or all 0s. For example the register with smin_value==1 doesn't mean that s32_min_value is also equal to 1, since smax_value could be larger than 32-bit subregister can hold. The verifier refines the smax/s32_max return value from certain helpers in do_refine_retval_range(). Teach the verifier to recognize that smin/s32_min value is also bounded. When both smin and smax bounds fit into 32-bit subregister the verifier can propagate those bounds. Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") Reported-by: Jean-Philippe Brucker Acked-by: John Fastabend Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit f03bcb61241789022e1e4c43b03a090a3429b170 Author: Jakub Kicinski Date: Wed Dec 9 14:39:56 2020 -0800 Revert "geneve: pull IP header before ECN decapsulation" commit c02bd115b1d25931159f89c7d9bf47a30f5d4b41 upstream. This reverts commit 4179b00c04d1 ("geneve: pull IP header before ECN decapsulation"). Eric says: "network header should have been pulled already before hitting geneve_rx()". Let's revert the syzbot fix since it's causing more harm than good, and revisit. Suggested-by: Eric Dumazet Reported-by: Jianlin Shi Fixes: 4179b00c04d1 ("geneve: pull IP header before ECN decapsulation") Link: https://bugzilla.kernel.org/show_bug.cgi?id=210569 Link: https://lore.kernel.org/netdev/CANn89iJVWfb=2i7oU1=D55rOyQnBbbikf+Mc6XHMkY7YX-yGEw@mail.gmail.com/ Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e7a9b51b7e1fc8ca42856d1ecbba76165d29f55f Author: Masami Hiramatsu Date: Thu Dec 3 13:50:50 2020 +0900 x86/insn-eval: Use new for_each_insn_prefix() macro to loop over prefixes bytes commit 12cb908a11b2544b5f53e9af856e6b6a90ed5533 upstream Since insn.prefixes.nbytes can be bigger than the size of insn.prefixes.bytes[] when a prefix is repeated, the proper check must be insn.prefixes.bytes[i] != 0 and i < 4 instead of using insn.prefixes.nbytes. Use the new for_each_insn_prefix() macro which does it correctly. Debugged by Kees Cook . [ bp: Massage commit message. ] Fixes: 32d0b95300db ("x86/insn-eval: Add utility functions to get segment selector") Reported-by: syzbot+9b64b619f10f19d19a7c@syzkaller.appspotmail.com Signed-off-by: Masami Hiramatsu Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/160697104969.3146288.16329307586428270032.stgit@devnote2 [sudip: adjust context] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 5c2b4b4f9fa5b765b927e361e3d310bcb5773015 Author: Pablo Neira Ayuso Date: Wed Nov 25 23:50:17 2020 +0100 netfilter: nftables_offload: build mask based from the matching bytes commit a5d45bc0dc50f9dd83703510e9804d813a9cac32 upstream. Userspace might match on prefix bytes of header fields if they are on the byte boundary, this requires that the mask is adjusted accordingly. Use NFT_OFFLOAD_MATCH_EXACT() for meta since prefix byte matching is not allowed for this type of selector. The bitwise expression might be optimized out by userspace, hence the kernel needs to infer the prefix from the number of payload bytes to match on. This patch adds nft_payload_offload_mask() to calculate the bitmask to match on the prefix. Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 10208757f7bac16b55b0eaf3b6908482eefc87cb Author: Pablo Neira Ayuso Date: Wed Nov 25 23:50:07 2020 +0100 netfilter: nftables_offload: set address type in control dissector commit 3c78e9e0d33a27ab8050e4492c03c6a1f8d0ed6b upstream. This patch adds nft_flow_rule_set_addr_type() to set the address type from the nft_payload expression accordingly. If the address type is not set in the control dissector then a rule that matches either on source or destination IP address does not work. After this patch, nft hardware offload generates the flow dissector configuration as tc-flower does to match on an IP address. This patch has been also tested functionally to make sure packets are filtered out by the NIC. This is also getting the code aligned with the existing netfilter flow offload infrastructure which is also setting the control dissector. Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 182099ac9e83d7218ca373d72e263f62d2a51b76 Author: Florian Westphal Date: Thu Nov 19 16:34:54 2020 +0100 netfilter: nf_tables: avoid false-postive lockdep splat commit c0700dfa2cae44c033ed97dade8a2679c7d22a9d upstream. There are reports wrt lockdep splat in nftables, e.g.: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 31416 at net/netfilter/nf_tables_api.c:622 lockdep_nfnl_nft_mutex_not_held+0x28/0x38 [nf_tables] ... These are caused by an earlier, unrelated bug such as a n ABBA deadlock in a different subsystem. In such an event, lockdep is disabled and lockdep_is_held returns true unconditionally. This then causes the WARN() in nf_tables. Make the WARN conditional on lockdep still active to avoid this. Fixes: f102d66b335a417 ("netfilter: nf_tables: use dedicated mutex to guard transactions") Reported-by: Naresh Kamboju Link: https://lore.kernel.org/linux-kselftest/CA+G9fYvFUpODs+NkSYcnwKnXm62tmP=ksLeBPmB+KFrB2rvCtQ@mail.gmail.com/ Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit ec62f9cdf6d428b56b1964a5d90ee9b61492b6f5 Author: Luo Meng Date: Tue Nov 24 17:45:23 2020 -0800 Input: i8042 - fix error return code in i8042_setup_aux() commit 855b69857830f8d918d715014f05e59a3f7491a0 upstream. Fix to return a negative error code from the error handling case instead of 0 in function i8042_setup_aux(), as done elsewhere in this function. Fixes: f81134163fc7 ("Input: i8042 - use platform_driver_probe") Reported-by: Hulk Robot Signed-off-by: Luo Meng Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20201123133420.4071187-1-luomeng12@huawei.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 0654a224a9d82d62d2a51740eacc1a986570c810 Author: Mike Snitzer Date: Fri Nov 13 14:52:28 2020 -0800 dm writecache: remove BUG() and fail gracefully instead commit 857c4c0a8b2888d806f4308c58f59a6a81a1dee9 upstream. Building on arch/s390/ results in this build error: cc1: some warnings being treated as errors ../drivers/md/dm-writecache.c: In function 'persistent_memory_claim': ../drivers/md/dm-writecache.c:323:1: error: no return statement in function returning non-void [-Werror=return-type] Fix this by replacing the BUG() with an -EOPNOTSUPP return. Fixes: 48debafe4f2f ("dm: add writecache target") Reported-by: Randy Dunlap Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit b85ca7d11c61e81a644d3658a86c79e0cec6c6a7 Author: Zhihao Cheng Date: Mon Nov 16 22:10:58 2020 +0800 i2c: qup: Fix error return code in qup_i2c_bam_schedule_desc() commit e9acf0298c664f825e6f1158f2a97341bf9e03ca upstream. Fix to return the error code from qup_i2c_change_state() instaed of 0 in qup_i2c_bam_schedule_desc(). Fixes: fbf9921f8b35d9b2 ("i2c: qup: Fix error handling") Reported-by: Hulk Robot Signed-off-by: Zhihao Cheng Reviewed-by: Bjorn Andersson Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 97783a290bf97374c5c542cb105bd0e064612cce Author: Robert Foss Date: Mon Nov 30 11:04:45 2020 +0100 i2c: qcom: Fix IRQ error misassignement commit 14718b3e129b058cb716a60c6faf40ef68661c54 upstream. During cci_isr() errors read from register fields belonging to i2c master1 are currently assigned to the status field belonging to i2c master0. This patch corrects this error, and always assigns master1 errors to the status field of master1. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Reported-by: Loic Poulain Suggested-by: Loic Poulain Signed-off-by: Robert Foss Reviewed-by: Manivannan Sadhasivam Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 50b2164c66b67c32a4a8a38c7511aa76f73adbc7 Author: Dan Carpenter Date: Thu Dec 3 11:43:37 2020 +0300 rtw88: debug: Fix uninitialized memory in debugfs code commit 74a8c816fa8fa7862df870660e9821abb56649fe upstream. This code does not ensure that the whole buffer is initialized and none of the callers check for errors so potentially none of the buffer is initialized. Add a memset to eliminate this bug. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/X8ilOfVz3pf0T5ec@mwanda Signed-off-by: Greg Kroah-Hartman commit 312d5fc71f1b49862457ec3049a1f357d53771ad Author: Bob Peterson Date: Tue Nov 24 10:41:40 2020 -0600 gfs2: Don't freeze the file system during unmount commit f39e7d3aae2934b1cfdd209b54c508e2552e9531 upstream. GFS2's freeze/thaw mechanism uses a special freeze glock to control its operation. It does this with a sync glock operation (glops.c) called freeze_go_sync. When the freeze glock is demoted (glock's do_xmote) the glops function causes the file system to be frozen. This is intended. However, GFS2's mount and unmount processes also hold the freeze glock to prevent other processes, perhaps on different cluster nodes, from mounting the frozen file system in read-write mode. Before this patch, there was no check in freeze_go_sync for whether a freeze in intended or whether the glock demote was caused by a normal unmount. So it was trying to freeze the file system it's trying to unmount, which ends up in a deadlock. This patch adds an additional check to freeze_go_sync so that demotes of the freeze glock are ignored if they come from the unmount process. Fixes: 20b329129009 ("gfs2: Fix regression in freeze_go_sync") Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit c0c5b2ebdf28fc91952ad70e60e15ce83278139e Author: Alexander Aring Date: Sun Nov 22 18:10:24 2020 -0500 gfs2: Fix deadlock dumping resource group glocks commit 16e6281b6b22b0178eab95c6a82502d7b10f67b8 upstream. Commit 0e539ca1bbbe ("gfs2: Fix NULL pointer dereference in gfs2_rgrp_dump") introduced additional locking in gfs2_rgrp_go_dump, which is also used for dumping resource group glocks via debugfs. However, on that code path, the glock spin lock is already taken in dump_glock, and taking it again in gfs2_glock2rgrp leads to deadlock. This can be reproduced with: $ mkfs.gfs2 -O -p lock_nolock /dev/FOO $ mount /dev/FOO /mnt/foo $ touch /mnt/foo/bar $ cat /sys/kernel/debug/gfs2/FOO/glocks Fix that by not taking the glock spin lock inside the go_dump callback. Fixes: 0e539ca1bbbe ("gfs2: Fix NULL pointer dereference in gfs2_rgrp_dump") Signed-off-by: Alexander Aring Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 17c8d31778f52f98d648fcfef685df0b6115dd4f Author: Luo Meng Date: Mon Nov 23 21:38:39 2020 +0800 ASoC: wm_adsp: fix error return code in wm_adsp_load() commit 3fba05a2832f93b4d0cd4204f771fdae0d823114 upstream. Fix to return a negative error code from the error handling case instead of 0 in function wm_adsp_load(), as done elsewhere in this function. Fixes: 170b1e123f38 ("ASoC: wm_adsp: Add support for new Halo core DSPs") Reported-by: Hulk Robot Signed-off-by: Luo Meng Acked-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20201123133839.4073787-1-luomeng12@huawei.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1716c9bd567bc6cdb3d18be78f36941a306b708d Author: Hoang Huu Le Date: Mon Sep 7 13:17:25 2020 +0700 tipc: fix a deadlock when flushing scheduled work commit d966ddcc38217a6110a6a0ff37ad2dee7d42e23e upstream. In the commit fdeba99b1e58 ("tipc: fix use-after-free in tipc_bcast_get_mode"), we're trying to make sure the tipc_net_finalize_work work item finished if it enqueued. But calling flush_scheduled_work() is not just affecting above work item but either any scheduled work. This has turned out to be overkill and caused to deadlock as syzbot reported: ====================================================== WARNING: possible circular locking dependency detected 5.9.0-rc2-next-20200828-syzkaller #0 Not tainted ------------------------------------------------------ kworker/u4:6/349 is trying to acquire lock: ffff8880aa063d38 ((wq_completion)events){+.+.}-{0:0}, at: flush_workqueue+0xe1/0x13e0 kernel/workqueue.c:2777 but task is already holding lock: ffffffff8a879430 (pernet_ops_rwsem){++++}-{3:3}, at: cleanup_net+0x9b/0xb10 net/core/net_namespace.c:565 [...] Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pernet_ops_rwsem); lock(&sb->s_type->i_mutex_key#13); lock(pernet_ops_rwsem); lock((wq_completion)events); *** DEADLOCK *** [...] v1: To fix the original issue, we replace above calling by introducing a bit flag. When a namespace cleaned-up, bit flag is set to zero and: - tipc_net_finalize functionial just does return immediately. - tipc_net_finalize_work does not enqueue into the scheduled work queue. v2: Use cancel_work_sync() helper to make sure ONLY the tipc_net_finalize_work() stopped before releasing bcbase object. Reported-by: syzbot+d5aa7e0385f6a5d0f4fd@syzkaller.appspotmail.com Fixes: fdeba99b1e58 ("tipc: fix use-after-free in tipc_bcast_get_mode") Acked-by: Jon Maloy Signed-off-by: Hoang Huu Le Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 844fb0454edb19b61a77284f54399cadf264adc8 Author: Eric Dumazet Date: Thu Nov 19 01:59:32 2020 -0800 netfilter: ipset: prevent uninit-value in hash_ip6_add commit 68ad89de918e1c5a79c9c56127e5e31741fd517e upstream. syzbot found that we are not validating user input properly before copying 16 bytes [1]. Using NLA_BINARY in ipaddr_policy[] for IPv6 address is not correct, since it ensures at most 16 bytes were provided. We should instead make sure user provided exactly 16 bytes. In old kernels (before v4.20), fix would be to remove the NLA_BINARY, since NLA_POLICY_EXACT_LEN() was not yet available. [1] BUG: KMSAN: uninit-value in hash_ip6_add+0x1cba/0x3a50 net/netfilter/ipset/ip_set_hash_gen.h:892 CPU: 1 PID: 11611 Comm: syz-executor.0 Not tainted 5.10.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 hash_ip6_add+0x1cba/0x3a50 net/netfilter/ipset/ip_set_hash_gen.h:892 hash_ip6_uadt+0x976/0xbd0 net/netfilter/ipset/ip_set_hash_ip.c:267 call_ad+0x329/0xd00 net/netfilter/ipset/ip_set_core.c:1720 ip_set_ad+0x111f/0x1440 net/netfilter/ipset/ip_set_core.c:1808 ip_set_uadd+0xf6/0x110 net/netfilter/ipset/ip_set_core.c:1833 nfnetlink_rcv_msg+0xc7d/0xdf0 net/netfilter/nfnetlink.c:252 netlink_rcv_skb+0x70a/0x820 net/netlink/af_netlink.c:2494 nfnetlink_rcv+0x4f0/0x4380 net/netfilter/nfnetlink.c:600 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x11da/0x14b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x173c/0x1840 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] ____sys_sendmsg+0xc7a/0x1240 net/socket.c:2353 ___sys_sendmsg net/socket.c:2407 [inline] __sys_sendmsg+0x6d5/0x830 net/socket.c:2440 __do_sys_sendmsg net/socket.c:2449 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2447 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2447 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45deb9 Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fe2e503fc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000029ec0 RCX: 000000000045deb9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003 RBP: 000000000118bf60 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118bf2c R13: 000000000169fb7f R14: 00007fe2e50409c0 R15: 000000000118bf2c Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 ip6_netmask include/linux/netfilter/ipset/pfxlen.h:49 [inline] hash_ip6_netmask net/netfilter/ipset/ip_set_hash_ip.c:185 [inline] hash_ip6_uadt+0xb1c/0xbd0 net/netfilter/ipset/ip_set_hash_ip.c:263 call_ad+0x329/0xd00 net/netfilter/ipset/ip_set_core.c:1720 ip_set_ad+0x111f/0x1440 net/netfilter/ipset/ip_set_core.c:1808 ip_set_uadd+0xf6/0x110 net/netfilter/ipset/ip_set_core.c:1833 nfnetlink_rcv_msg+0xc7d/0xdf0 net/netfilter/nfnetlink.c:252 netlink_rcv_skb+0x70a/0x820 net/netlink/af_netlink.c:2494 nfnetlink_rcv+0x4f0/0x4380 net/netfilter/nfnetlink.c:600 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x11da/0x14b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x173c/0x1840 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] ____sys_sendmsg+0xc7a/0x1240 net/socket.c:2353 ___sys_sendmsg net/socket.c:2407 [inline] __sys_sendmsg+0x6d5/0x830 net/socket.c:2440 __do_sys_sendmsg net/socket.c:2449 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2447 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2447 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 kmsan_memcpy_memmove_metadata+0x25e/0x2d0 mm/kmsan/kmsan.c:226 kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:246 __msan_memcpy+0x46/0x60 mm/kmsan/kmsan_instr.c:110 ip_set_get_ipaddr6+0x2cb/0x370 net/netfilter/ipset/ip_set_core.c:310 hash_ip6_uadt+0x439/0xbd0 net/netfilter/ipset/ip_set_hash_ip.c:255 call_ad+0x329/0xd00 net/netfilter/ipset/ip_set_core.c:1720 ip_set_ad+0x111f/0x1440 net/netfilter/ipset/ip_set_core.c:1808 ip_set_uadd+0xf6/0x110 net/netfilter/ipset/ip_set_core.c:1833 nfnetlink_rcv_msg+0xc7d/0xdf0 net/netfilter/nfnetlink.c:252 netlink_rcv_skb+0x70a/0x820 net/netlink/af_netlink.c:2494 nfnetlink_rcv+0x4f0/0x4380 net/netfilter/nfnetlink.c:600 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x11da/0x14b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x173c/0x1840 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] ____sys_sendmsg+0xc7a/0x1240 net/socket.c:2353 ___sys_sendmsg net/socket.c:2407 [inline] __sys_sendmsg+0x6d5/0x830 net/socket.c:2440 __do_sys_sendmsg net/socket.c:2449 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2447 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2447 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_poison_shadow+0x5c/0xf0 mm/kmsan/kmsan.c:104 kmsan_slab_alloc+0x8d/0xe0 mm/kmsan/kmsan_hooks.c:76 slab_alloc_node mm/slub.c:2906 [inline] __kmalloc_node_track_caller+0xc61/0x15f0 mm/slub.c:4512 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0x309/0xae0 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1094 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1176 [inline] netlink_sendmsg+0xdb8/0x1840 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] ____sys_sendmsg+0xc7a/0x1240 net/socket.c:2353 ___sys_sendmsg net/socket.c:2407 [inline] __sys_sendmsg+0x6d5/0x830 net/socket.c:2440 __do_sys_sendmsg net/socket.c:2449 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2447 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2447 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: a7b4f989a629 ("netfilter: ipset: IP set core support") Signed-off-by: Eric Dumazet Reported-by: syzbot Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit cecb2b21c1de948505ef1119499d37e20cb990df Author: Bob Peterson Date: Tue Nov 24 10:44:36 2020 -0500 gfs2: check for empty rgrp tree in gfs2_ri_update commit 778721510e84209f78e31e2ccb296ae36d623f5e upstream. If gfs2 tries to mount a (corrupt) file system that has no resource groups it still tries to set preferences on the first one, which causes a kernel null pointer dereference. This patch adds a check to function gfs2_ri_update so this condition is detected and reported back as an error. Reported-by: syzbot+e3f23ce40269a4c9053a@syzkaller.appspotmail.com Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 1b1e68927e09bad4a29624e494fd7a73c1b7719b Author: Oliver Hartkopp Date: Thu Nov 26 20:21:40 2020 +0100 can: af_can: can_rx_unregister(): remove WARN() statement from list operation sanity check commit d73ff9b7c4eacaba0fd956d14882bcae970f8307 upstream. To detect potential bugs in CAN protocol implementations (double removal of receiver entries) a WARN() statement has been used if no matching list item was found for removal. The fault injection issued by syzkaller was able to create a situation where the closing of a socket runs simultaneously to the notifier call chain for removing the CAN network device in use. This case is very unlikely in real life but it doesn't break anything. Therefore we just replace the WARN() statement with pr_warn() to preserve the notification for the CAN protocol development. Reported-by: syzbot+381d06e0c8eaacb8706f@syzkaller.appspotmail.com Reported-by: syzbot+d0ddd88c9a7432f041e6@syzkaller.appspotmail.com Reported-by: syzbot+76d62d3b8162883c7d11@syzkaller.appspotmail.com Signed-off-by: Oliver Hartkopp Link: https://lore.kernel.org/r/20201126192140.14350-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit bc6ca732f4a4dce79abd0fdeb81fc5c20e01fd0a Author: Willy Tarreau Date: Mon Nov 30 08:36:48 2020 +0100 lib/syscall: fix syscall registers retrieval on 32-bit platforms commit 4f134b89a24b965991e7c345b9a4591821f7c2a6 upstream. Lilith >_> and Claudio Bozzato of Cisco Talos security team reported that collect_syscall() improperly casts the syscall registers to 64-bit values leaking the uninitialized last 24 bytes on 32-bit platforms, that are visible in /proc/self/syscall. The cause is that info->data.args are u64 while syscall_get_arguments() uses longs, as hinted by the bogus pointer cast in the function. Let's just proceed like the other call places, by retrieving the registers into an array of longs before assigning them to the caller's array. This was successfully tested on x86_64, i386 and ppc32. Reference: CVE-2020-28588, TALOS-2020-1211 Fixes: 631b7abacd02 ("ptrace: Remove maxargs from task_current_syscall()") Cc: Greg KH Reviewed-by: Kees Cook Tested-by: Michael Ellerman (ppc32) Signed-off-by: Willy Tarreau Reviewed-by: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 67dc2e5d2ec59da26581b27bacecc02db7b40858 Author: Roman Gushchin Date: Sat Dec 5 22:14:45 2020 -0800 mm: memcg/slab: fix obj_cgroup_charge() return value handling commit becaba65f62f88e553ec92ed98370e9d2b18e629 upstream. Commit 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all allocations") introduced a regression into the handling of the obj_cgroup_charge() return value. If a non-zero value is returned (indicating of exceeding one of memory.max limits), the allocation should fail, instead of falling back to non-accounted mode. To make the code more readable, move memcg_slab_pre_alloc_hook() and memcg_slab_post_alloc_hook() calling conditions into bodies of these hooks. Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all allocations") Signed-off-by: Roman Gushchin Signed-off-by: Andrew Morton Reviewed-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Hocko Cc: Link: https://lkml.kernel.org/r/20201127161828.GD840171@carbon.dhcp.thefacebook.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bc765e0f7c25464e64b62c241c774d88528565c6 Author: Suravee Suthikulpanit Date: Mon Dec 7 03:19:20 2020 -0600 iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs commit 4165bf015ba9454f45beaad621d16c516d5c5afe upstream. According to the AMD IOMMU spec, the commit 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to 512 entries") also requires the interrupt table length (IntTabLen) to be set to 9 (power of 2) in the device table mapping entry (DTE). Fixes: 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to 512 entries") Reported-by: Jerry Snitselaar Signed-off-by: Suravee Suthikulpanit Reviewed-by: Jerry Snitselaar Link: https://lore.kernel.org/r/20201207091920.3052-1-suravee.suthikulpanit@amd.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 1ad9dd490a014372287cfd40abc73423654e2a81 Author: Alex Deucher Date: Wed Dec 9 10:42:22 2020 -0500 Revert "amd/amdgpu: Disable VCN DPG mode for Picasso" This patch should not have been applied to stable. It depends on changes in newer drivers. This reverts commit 756fec062e4b823bbbe10b95cbcfa84f948131c6. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1402 Signed-off-by: Alex Deucher Cc: Sasha Levin Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e3861ec49e9e0627fc8b82f2fc3dfa16912e768f Author: Mike Kravetz Date: Sat Dec 5 22:15:12 2020 -0800 hugetlb_cgroup: fix offline of hugetlb cgroup with reservations commit 7a5bde37983d37783161681ff7c6122dfd081791 upstream. Adrian Moreno was ruuning a kubernetes 1.19 + containerd/docker workload using hugetlbfs. In this environment the issue is reproduced by: - Start a simple pod that uses the recently added HugePages medium feature (pod yaml attached) - Start a DPDK app. It doesn't need to run successfully (as in transfer packets) nor interact with real hardware. It seems just initializing the EAL layer (which handles hugepage reservation and locking) is enough to trigger the issue - Delete the Pod (or let it "Complete"). This would result in a kworker thread going into a tight loop (top output): 1425 root 20 0 0 0 0 R 99.7 0.0 5:22.45 kworker/28:7+cgroup_destroy 'perf top -g' reports: - 63.28% 0.01% [kernel] [k] worker_thread - 49.97% worker_thread - 52.64% process_one_work - 62.08% css_killed_work_fn - hugetlb_cgroup_css_offline 41.52% _raw_spin_lock - 2.82% _cond_resched rcu_all_qs 2.66% PageHuge - 0.57% schedule - 0.57% __schedule We are spinning in the do-while loop in hugetlb_cgroup_css_offline. Worse yet, we are holding the master cgroup lock (cgroup_mutex) while infinitely spinning. Little else can be done on the system as the cgroup_mutex can not be acquired. Do note that the issue can be reproduced by simply offlining a hugetlb cgroup containing pages with reservation counts. The loop in hugetlb_cgroup_css_offline is moving page counts from the cgroup being offlined to the parent cgroup. This is done for each hstate, and is repeated until hugetlb_cgroup_have_usage returns false. The routine moving counts (hugetlb_cgroup_move_parent) is only moving 'usage' counts. The routine hugetlb_cgroup_have_usage is checking for both 'usage' and 'reservation' counts. Discussion about what to do with reservation counts when reparenting was discussed here: https://lore.kernel.org/linux-kselftest/CAHS8izMFAYTgxym-Hzb_JmkTK1N_S9tGN71uS6MFV+R7swYu5A@mail.gmail.com/ The decision was made to leave a zombie cgroup for with reservation counts. Unfortunately, the code checking reservation counts was incorrectly added to hugetlb_cgroup_have_usage. To fix the issue, simply remove the check for reservation counts. While fixing this issue, a related bug in hugetlb_cgroup_css_offline was noticed. The hstate index is not reinitialized each time through the do-while loop. Fix this as well. Fixes: 1adc4d419aa2 ("hugetlb_cgroup: add interface for charge/uncharge hugetlb reservations") Reported-by: Adrian Moreno Signed-off-by: Mike Kravetz Signed-off-by: Andrew Morton Tested-by: Adrian Moreno Reviewed-by: Shakeel Butt Cc: Mina Almasry Cc: David Rientjes Cc: Greg Thelen Cc: Sandipan Das Cc: Shuah Khan Cc: Link: https://lkml.kernel.org/r/20201203220242.158165-1-mike.kravetz@oracle.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 406572286ff504147e902f937db325873a3b3fa2 Author: Qian Cai Date: Sat Dec 5 22:14:55 2020 -0800 mm/swapfile: do not sleep with a spin lock held commit b11a76b37a5aa7b07c3e3eeeaae20b25475bddd3 upstream. We can't call kvfree() with a spin lock held, so defer it. Fixes a might_sleep() runtime warning. Fixes: 873d7bcfd066 ("mm/swapfile.c: use kvzalloc for swap_info_struct allocation") Signed-off-by: Qian Cai Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Hugh Dickins Cc: Link: https://lkml.kernel.org/r/20201202151549.10350-1-qcai@redhat.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c07e0a85d52076a485e3ee6e485db3f1863dfd5b Author: Yang Shi Date: Sat Dec 5 22:14:48 2020 -0800 mm: list_lru: set shrinker map bit when child nr_items is not zero commit 8199be001a470209f5c938570cc199abb012fe53 upstream. When investigating a slab cache bloat problem, significant amount of negative dentry cache was seen, but confusingly they neither got shrunk by reclaimer (the host has very tight memory) nor be shrunk by dropping cache. The vmcore shows there are over 14M negative dentry objects on lru, but tracing result shows they were even not scanned at all. Further investigation shows the memcg's vfs shrinker_map bit is not set. So the reclaimer or dropping cache just skip calling vfs shrinker. So we have to reboot the hosts to get the memory back. I didn't manage to come up with a reproducer in test environment, and the problem can't be reproduced after rebooting. But it seems there is race between shrinker map bit clear and reparenting by code inspection. The hypothesis is elaborated as below. The memcg hierarchy on our production environment looks like: root / \ system user The main workloads are running under user slice's children, and it creates and removes memcg frequently. So reparenting happens very often under user slice, but no task is under user slice directly. So with the frequent reparenting and tight memory pressure, the below hypothetical race condition may happen: CPU A CPU B reparent dst->nr_items == 0 shrinker: total_objects == 0 add src->nr_items to dst set_bit return SHRINK_EMPTY clear_bit child memcg offline replace child's kmemcg_id with parent's (in memcg_offline_kmem()) list_lru_del() between shrinker runs see parent's kmemcg_id dec dst->nr_items reparent again dst->nr_items may go negative due to concurrent list_lru_del() The second run of shrinker: read nr_items without any synchronization, so it may see intermediate negative nr_items then total_objects may return 0 coincidently keep the bit cleared dst->nr_items != 0 skip set_bit add scr->nr_item to dst After this point dst->nr_item may never go zero, so reparenting will not set shrinker_map bit anymore. And since there is no task under user slice directly, so no new object will be added to its lru to set the shrinker map bit either. That bit is kept cleared forever. How does list_lru_del() race with reparenting? It is because reparenting replaces children's kmemcg_id to parent's without protecting from nlru->lock, so list_lru_del() may see parent's kmemcg_id but actually deleting items from child's lru, but dec'ing parent's nr_items, so the parent's nr_items may go negative as commit 2788cf0c401c ("memcg: reparent list_lrus and free kmemcg_id on css offline") says. Since it is impossible that dst->nr_items goes negative and src->nr_items goes zero at the same time, so it seems we could set the shrinker map bit iff src->nr_items != 0. We could synchronize list_lru_count_one() and reparenting with nlru->lock, but it seems checking src->nr_items in reparenting is the simplest and avoids lock contention. Fixes: fae91d6d8be5 ("mm/list_lru.c: set bit in memcg shrinker bitmap on first list_lru item appearance") Suggested-by: Roman Gushchin Signed-off-by: Yang Shi Signed-off-by: Andrew Morton Reviewed-by: Roman Gushchin Reviewed-by: Shakeel Butt Acked-by: Kirill Tkhai Cc: Vladimir Davydov Cc: [4.19] Link: https://lkml.kernel.org/r/20201202171749.264354-1-shy828301@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4140456090f833dfc663ff08e92211f46b4c2c1a Author: Menglong Dong Date: Sat Dec 5 22:14:42 2020 -0800 coredump: fix core_pattern parse error commit 2bf509d96d84c3336d08375e8af34d1b85ee71c8 upstream. 'format_corename()' will splite 'core_pattern' on spaces when it is in pipe mode, and take helper_argv[0] as the path to usermode executable. It works fine in most cases. However, if there is a space between '|' and '/file/path', such as '| /usr/lib/systemd/systemd-coredump %P %u %g', then helper_argv[0] will be parsed as '', and users will get a 'Core dump to | disabled'. It is not friendly to users, as the pattern above was valid previously. Fix this by ignoring the spaces between '|' and '/file/path'. Fixes: 315c69261dd3 ("coredump: split pipe command whitespace before expanding template") Signed-off-by: Menglong Dong Signed-off-by: Andrew Morton Cc: Paul Wise Cc: Jakub Wilk [https://bugs.debian.org/924398] Cc: Neil Horman Cc: Link: https://lkml.kernel.org/r/5fb62870.1c69fb81.8ef5d.af76@mx.google.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5655e4c9c96aaa469cdcc0747cbcc11bc78d339d Author: Masami Hiramatsu Date: Thu Dec 3 13:50:37 2020 +0900 x86/uprobes: Do not use prefixes.nbytes when looping over prefixes.bytes commit 4e9a5ae8df5b3365183150f6df49e49dece80d8c upstream. Since insn.prefixes.nbytes can be bigger than the size of insn.prefixes.bytes[] when a prefix is repeated, the proper check must be insn.prefixes.bytes[i] != 0 and i < 4 instead of using insn.prefixes.nbytes. Introduce a for_each_insn_prefix() macro for this purpose. Debugged by Kees Cook . [ bp: Massage commit message, sync with the respective header in tools/ and drop "we". ] Fixes: 2b1444983508 ("uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints") Reported-by: syzbot+9b64b619f10f19d19a7c@syzkaller.appspotmail.com Signed-off-by: Masami Hiramatsu Signed-off-by: Borislav Petkov Reviewed-by: Srikar Dronamraju Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/160697103739.3146288.7437620795200799020.stgit@devnote2 Signed-off-by: Greg Kroah-Hartman commit 422e24487fceacc9cd961c39f93e74bbfd6dce05 Author: Mike Snitzer Date: Fri Dec 4 15:25:18 2020 -0500 dm: remove invalid sparse __acquires and __releases annotations commit bde3808bc8c2741ad3d804f84720409aee0c2972 upstream. Fixes sparse warnings: drivers/md/dm.c:508:12: warning: context imbalance in 'dm_prepare_ioctl' - wrong count at exit drivers/md/dm.c:543:13: warning: context imbalance in 'dm_unprepare_ioctl' - wrong count at exit Fixes: 971888c46993f ("dm: hold DM table for duration of ioctl rather than use blkdev_get") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 8f602268285452217da920fffc7040d7cf274181 Author: Mike Snitzer Date: Fri Dec 4 15:19:27 2020 -0500 dm: fix double RCU unlock in dm_dax_zero_page_range() error path commit f05c4403db5bba881d4964e731f6da35be46aabd upstream. Remove redundant dm_put_live_table() in dm_dax_zero_page_range() error path to fix sparse warning: drivers/md/dm.c:1208:9: warning: context imbalance in 'dm_dax_zero_page_range' - unexpected unlock Fixes: cdf6cdcd3b99a ("dm,dax: Add dax zero_page_range operation") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 5f0612de7662fdd25f8de546b95e567ecceba175 Author: Sergei Shtepa Date: Wed Nov 11 15:55:46 2020 +0300 dm: fix bug with RCU locking in dm_blk_report_zones commit 89478335718c98557f10470a9bc5c555b9261c4e upstream. The dm_get_live_table() function makes RCU read lock so dm_put_live_table() must be called even if dm_table map is not found. Fixes: e76239a3748c9 ("block: add a report_zones method") Cc: stable@vger.kernel.org Signed-off-by: Sergei Shtepa Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 732630a290d2c0f20c9c117d1b60fd2fade3b7b7 Author: Laurent Vivier Date: Thu Nov 26 09:28:52 2020 +0100 powerpc/pseries: Pass MSI affinity to irq_create_mapping() commit 9ea69a55b3b9a71cded9726af591949c1138f235 upstream. With virtio multiqueue, normally each queue IRQ is mapped to a CPU. Commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity") exposed an existing shortcoming of the arch code by moving virtio_scsi to the automatic IRQ affinity assignment. The affinity is correctly computed in msi_desc but this is not applied to the system IRQs. It appears the affinity is correctly passed to rtas_setup_msi_irqs() but lost at this point and never passed to irq_domain_alloc_descs() (see commit 06ee6d571f0e ("genirq: Add affinity hint to irq allocation")) because irq_create_mapping() doesn't take an affinity parameter. Use the new irq_create_mapping_affinity() function, which allows to forward the affinity setting from rtas_setup_msi_irqs() to irq_domain_alloc_descs(). With this change, the virtqueues are correctly dispatched between the CPUs on pseries. Fixes: e75eafb9b039 ("genirq/msi: Switch to new irq spreading infrastructure") Signed-off-by: Laurent Vivier Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kurz Acked-by: Michael Ellerman Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201126082852.1178497-3-lvivier@redhat.com Signed-off-by: Greg Kroah-Hartman commit b732e2c47f5925538917a34aff5ca7d120100a68 Author: Laurent Vivier Date: Thu Nov 26 09:28:51 2020 +0100 genirq/irqdomain: Add an irq_create_mapping_affinity() function commit bb4c6910c8b41623104c2e64a30615682689a54d upstream. There is currently no way to convey the affinity of an interrupt via irq_create_mapping(), which creates issues for devices that expect that affinity to be managed by the kernel. In order to sort this out, rename irq_create_mapping() to irq_create_mapping_affinity() with an additional affinity parameter that can be passed down to irq_domain_alloc_descs(). irq_create_mapping() is re-implemented as a wrapper around irq_create_mapping_affinity(). No functional change. Fixes: e75eafb9b039 ("genirq/msi: Switch to new irq spreading infrastructure") Signed-off-by: Laurent Vivier Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kurz Cc: Michael Ellerman Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201126082852.1178497-2-lvivier@redhat.com Signed-off-by: Greg Kroah-Hartman commit 64316364fdaa5a447340ffe6f39b861826f8412e Author: Nicholas Piggin Date: Sat Nov 28 17:07:21 2020 +1000 powerpc/64s/powernv: Fix memory corruption when saving SLB entries on MCE commit a1ee28117077c3bf24e5ab6324c835eaab629c45 upstream. This can be hit by an HPT guest running on an HPT host and bring down the host, so it's quite important to fix. Fixes: 7290f3b3d3e6 ("powerpc/64s/powernv: machine check dump SLB contents") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Nicholas Piggin Acked-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201128070728.825934-2-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 05b9eff050a5d12efa932ca2d7782abe866f8386 Author: Mikulas Patocka Date: Tue Nov 10 07:45:13 2020 -0500 dm writecache: fix the maximum number of arguments commit 67aa3ec3dbc43d6e34401d9b2a40040ff7bb57af upstream. Advance the maximum number of arguments to 16. This fixes issue where certain operations, combined with table configured args, exceed 10 arguments. Signed-off-by: Mikulas Patocka Fixes: 48debafe4f2f ("dm: add writecache target") Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 1b86b92f62480ef244bcb5a40f7a5c7e1021c549 Author: Mikulas Patocka Date: Tue Nov 10 07:44:01 2020 -0500 dm writecache: advance the number of arguments when reporting max_age commit e5d41cbca1b2036362c9e29d705d3a175a01eff8 upstream. When reporting the "max_age" value the number of arguments must advance by two. Signed-off-by: Mikulas Patocka Fixes: 3923d4854e18 ("dm writecache: implement gradual cleanup") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 56306143ef9a4d07f92511a5ac81bbbc8b5c1cae Author: Pavel Begunkov Date: Sun Nov 29 18:33:32 2020 +0000 io_uring: fix recvmsg setup with compat buf-select commit 2d280bc8930ba9ed1705cfd548c6c8924949eaf1 upstream. __io_compat_recvmsg_copy_hdr() with REQ_F_BUFFER_SELECT reads out iov len but never assigns it to iov/fast_iov, leaving sr->len with garbage. Hopefully, following io_buffer_select() truncates it to the selected buffer size, but the value is still may be under what was specified. Cc: # 5.7 Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c0d09be5a87f7b8662094be764d42da0d3f5876b Author: Suganath Prabu S Date: Wed Nov 25 15:18:38 2020 +0530 scsi: mpt3sas: Fix ioctl timeout commit 42f687038bcc34aa919e0e4c29b04e4cda3f6a79 upstream. Commit c1a6c5ac4278 ("scsi: mpt3sas: For NVME device, issue a protocol level reset") modified the ioctl path 'timeout' variable type to u8 from unsigned long, limiting the maximum timeout value that the driver can support to 255 seconds. If the management application is requesting a higher value the resulting timeout will be zero. The operation times out immediately and the ioctl request fails. Change datatype back to unsigned long. Link: https://lore.kernel.org/r/20201125094838.4340-1-suganath-prabu.subramani@broadcom.com Fixes: c1a6c5ac4278 ("scsi: mpt3sas: For NVME device, issue a protocol level reset") Cc: #v4.18+ Signed-off-by: Suganath Prabu S Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit baaa49f71e26b82ca8752d63ab274a790b90de47 Author: Greg Kurz Date: Mon Nov 30 13:19:27 2020 +0100 KVM: PPC: Book3S HV: XIVE: Fix vCPU id sanity check commit f54db39fbe40731c40aefdd3bc26e7d56d668c64 upstream. Commit 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP block size configurable") updated kvmppc_xive_vcpu_id_valid() in a way that allows userspace to trigger an assertion in skiboot and crash the host: [ 696.186248988,3] XIVE[ IC 08 ] eq_blk != vp_blk (0 vs. 1) for target 0x4300008c/0 [ 696.186314757,0] Assert fail: hw/xive.c:2370:0 [ 696.186342458,0] Aborting! xive-kvCPU 0043 Backtrace: S: 0000000031e2b8f0 R: 0000000030013840 .backtrace+0x48 S: 0000000031e2b990 R: 000000003001b2d0 ._abort+0x4c S: 0000000031e2ba10 R: 000000003001b34c .assert_fail+0x34 S: 0000000031e2ba90 R: 0000000030058984 .xive_eq_for_target.part.20+0xb0 S: 0000000031e2bb40 R: 0000000030059fdc .xive_setup_silent_gather+0x2c S: 0000000031e2bc20 R: 000000003005a334 .opal_xive_set_vp_info+0x124 S: 0000000031e2bd20 R: 00000000300051a4 opal_entry+0x134 --- OPAL call token: 0x8a caller R1: 0xc000001f28563850 --- XIVE maintains the interrupt context state of non-dispatched vCPUs in an internal VP structure. We allocate a bunch of those on startup to accommodate all possible vCPUs. Each VP has an id, that we derive from the vCPU id for efficiency: static inline u32 kvmppc_xive_vp(struct kvmppc_xive *xive, u32 server) { return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server); } The KVM XIVE device used to allocate KVM_MAX_VCPUS VPs. This was limitting the number of concurrent VMs because the VP space is limited on the HW. Since most of the time, VMs run with a lot less vCPUs, commit 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP block size configurable") gave the possibility for userspace to tune the size of the VP block through the KVM_DEV_XIVE_NR_SERVERS attribute. The check in kvmppc_pack_vcpu_id() was changed from cpu < KVM_MAX_VCPUS * xive->kvm->arch.emul_smt_mode to cpu < xive->nr_servers * xive->kvm->arch.emul_smt_mode The previous check was based on the fact that the VP block had KVM_MAX_VCPUS entries and that kvmppc_pack_vcpu_id() guarantees that packed vCPU ids are below KVM_MAX_VCPUS. We've changed the size of the VP block, but kvmppc_pack_vcpu_id() has nothing to do with it and it certainly doesn't ensure that the packed vCPU ids are below xive->nr_servers. kvmppc_xive_vcpu_id_valid() might thus return true when the VM was configured with a non-standard VSMT mode, even if the packed vCPU id is higher than what we expect. We end up using an unallocated VP id, which confuses OPAL. The assert in OPAL is probably abusive and should be converted to a regular error that the kernel can handle, but we shouldn't really use broken VP ids in the first place. Fix kvmppc_xive_vcpu_id_valid() so that it checks the packed vCPU id is below xive->nr_servers, which is explicitly what we want. Fixes: 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP block size configurable") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by: Greg Kurz Reviewed-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/160673876747.695514.1809676603724514920.stgit@bahia.lan Signed-off-by: Greg Kroah-Hartman commit 1a587d49dccbb72e77a59ff0d25a41f4d5c8c63e Author: Chris Wilson Date: Thu Nov 26 14:08:41 2020 +0000 drm/i915/gt: Program mocs:63 for cache eviction on gen9 commit 777a7717d60ccdc9b84f35074f848d3f746fc3bf upstream. Ville noticed that the last mocs entry is used unconditionally by the HW when it performs cache evictions, and noted that while the value is not meant to be writable by the driver, we should program it to a reasonable value nevertheless. As it turns out, we can change the value of mocs:63 and the value we were programming into it would cause hard hangs in conjunction with atomic operations. v2: Add details from bspec about how it is used by HW Suggested-by: Ville Syrjälä Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707 Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS") Signed-off-by: Chris Wilson Cc: Ville Syrjälä Cc: Jason Ekstrand Cc: # v4.3+ Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20201126140841.1982-1-chris@chris-wilson.co.uk (cherry picked from commit 977933b5da7c16f39295c4c1d4259a58ece65dbe) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 4cbaf4a8d36ac82985b68b47fcdb56a294901941 Author: Chris Wilson Date: Tue Nov 24 18:35:21 2020 +0000 drm/i915/gt: Limit frequency drop to RPe on parking commit aff76ab795364569b1cac58c1d0bc7df956e3899 upstream. We treat idling the GT (intel_rps_park) as a downclock event, and reduce the frequency we intend to restart the GT with. Since the two workloads are likely related (e.g. a compositor rendering every 16ms), we want to carry the frequency and load information from across the idling. However, we do also need to update the frequencies so that workloads that run for less than 1ms are autotuned by RPS (otherwise we leave compositors running at max clocks, draining excess power). Conversely, if we try to run too slowly, the next workload has to run longer. Since there is a hysteresis in the power graph, below a certain frequency running a short workload for longer consumes more energy than running it slightly higher for less time. The exact balance point is unknown beforehand, but measurements with 30fps media playback indicate that RPe is a better choice. Reported-by: Edward Baker Tested-by: Edward Baker Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark") Signed-off-by: Chris Wilson Cc: Edward Baker Cc: Andi Shyti Cc: Lyude Paul Cc: # v5.8+ Reviewed-by: Rodrigo Vivi Reviewed-by: Andi Shyti Link: https://patchwork.freedesktop.org/patch/msgid/20201124183521.28623-1-chris@chris-wilson.co.uk (cherry picked from commit f7ed83cc1925f0b8ce2515044d674354035c3af9) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 32340631263cee18f6ae4a05eb6970542359e21a Author: Venkata Ramana Nayana Date: Fri Nov 27 12:07:16 2020 +0000 drm/i915/gt: Retain default context state across shrinking commit 78b2eb8a1f10f366681acad8d21c974c1f66791a upstream. As we use a shmemfs file to hold the context state, when not in use it may be swapped out, such as across suspend. Since we wrote into the shmemfs without marking the pages as dirty, the contents may be dropped instead of being written back to swap. On re-using the shmemfs file, such as creating a new context after resume, the contents of that file were likely garbage and so the new context could then hang the GPU. Simply mark the page as being written when copying into the shmemfs file, and it the new contents will be retained across swapout. Fixes: be1cb55a07bf ("drm/i915/gt: Keep a no-frills swappable copy of the default context state") Cc: Sudeep Dutt Cc: Matthew Auld Cc: Tvrtko Ursulin Cc: Ramalingam C Signed-off-by: CQ Tang Signed-off-by: Venkata Ramana Nayana Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Cc: # v5.8+ Link: https://patchwork.freedesktop.org/patch/msgid/20201127120718.454037-161-matthew.auld@intel.com (cherry picked from commit a9d71f76ccfd309f3bd5f7c9b60e91a4decae792) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit c725702528bb3627ff1f3c44b10d4c79cbfa1d9b Author: Boyuan Zhang Date: Tue May 19 11:38:44 2020 -0400 drm/amdgpu/vcn3.0: remove old DPG workaround commit efd6d85a18102241538dd1cc257948a0dbe6fae6 upstream. Port from VCN2.5 SCRATCH2 is used to keep decode wptr as a workaround which fix a hardware DPG decode wptr update bug for vcn2.5 beforehand. Signed-off-by: Boyuan Zhang Reviewed-by: James Zhu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 5.9.x Signed-off-by: Greg Kroah-Hartman commit e2731a93ad16204e890f52c6a773b526550e097a Author: Boyuan Zhang Date: Sun May 10 15:47:03 2020 -0400 drm/amdgpu/vcn3.0: stall DPG when WPTR/RPTR reset commit ac2db9488cf21de0be7899c1e5963e5ac0ff351f upstream. Port from VCN2.5 Add vcn dpg harware synchronization to fix race condition issue between vcn driver and hardware. Signed-off-by: Boyuan Zhang Reviewed-by: James Zhu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 5.9.x Signed-off-by: Greg Kroah-Hartman commit 4560a448cb414b9f757c4900810d9c60d9f80cca Author: Tomi Valkeinen Date: Fri Nov 27 10:52:41 2020 +0200 drm/omap: sdi: fix bridge enable/disable commit fd4e788e971ce763e50762d7b1a0048992949dd0 upstream. When the SDI output was converted to DRM bridge, the atomic versions of enable and disable funcs were used. This was not intended, as that would require implementing other atomic funcs too. This leads to: WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 drm_atomic_helper_commit_modeset_enables+0x134/0x268 and display not working. Fix this by using the legacy enable/disable funcs. Fixes: 8bef8a6d5da81b909a190822b96805a47348146f ("drm/omap: sdi: Register a drm_bridge") Reported-by: Aaro Koskinen Signed-off-by: Tomi Valkeinen Tested-by: Ivaylo Dimitrov Tested-by: Aaro Koskinen Reviewed-by: Laurent Pinchart Cc: stable@vger.kernel.org # v5.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20201127085241.848461-1-tomi.valkeinen@ti.com Signed-off-by: Greg Kroah-Hartman commit 44de69467e37a94f574ce9025b490f164a1fb4f0 Author: Mika Westerberg Date: Wed Nov 18 13:08:21 2020 +0200 thunderbolt: Fix use-after-free in remove_unplugged_switch() commit 600c0849cf86b75d86352f59745226273290986a upstream. Paulian reported a crash that happens when a dock is unplugged during hibernation: [78436.228217] thunderbolt 0-1: device disconnected [78436.228365] BUG: kernel NULL pointer dereference, address: 00000000000001e0 ... [78436.228397] RIP: 0010:icm_free_unplugged_children+0x109/0x1a0 ... [78436.228432] Call Trace: [78436.228439] icm_rescan_work+0x24/0x30 [78436.228444] process_one_work+0x1a3/0x3a0 [78436.228449] worker_thread+0x30/0x370 [78436.228454] ? process_one_work+0x3a0/0x3a0 [78436.228457] kthread+0x13d/0x160 [78436.228461] ? kthread_park+0x90/0x90 [78436.228465] ret_from_fork+0x1f/0x30 This happens because remove_unplugged_switch() calls tb_switch_remove() that releases the memory pointed by sw so the following lines reference to a memory that might be released already. Fix this by saving pointer to the parent device before calling tb_switch_remove(). Reported-by: Paulian Bogdan Marinca Fixes: 4f7c2e0d8765 ("thunderbolt: Make sure device runtime resume completes before taking domain lock") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Reviewed-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit f05f0db4db8bec05f4fa09d97870774f837ee9fe Author: Steven Rostedt (VMware) Date: Fri Dec 4 16:36:16 2020 -0500 tracing: Fix userstacktrace option for instances commit bcee5278958802b40ee8b26679155a6d9231783e upstream. When the instances were able to use their own options, the userstacktrace option was left hardcoded for the top level. This made the instance userstacktrace option bascially into a nop, and will confuse users that set it, but nothing happens (I was confused when it happened to me!) Cc: stable@vger.kernel.org Fixes: 16270145ce6b ("tracing: Add trace options for core options to instances") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit da4d792e74cecbee9c2e6f1a2db3dfd6849f6d45 Author: Christian Eggers Date: Fri Oct 9 13:03:20 2020 +0200 i2c: imx: Don't generate STOP condition if arbitration has been lost commit 61e6fe59ede155881a622f5901551b1cc8748f6a upstream. If arbitration is lost, the master automatically changes to slave mode. I2SR_IBB may or may not be reset by hardware. Raising a STOP condition by resetting I2CR_MSTA has no effect and will not clear I2SR_IBB. So calling i2c_imx_bus_busy() is not required and would busy-wait until timeout. Signed-off-by: Christian Eggers Tested (not extensively) on Vybrid VF500 (Toradex VF50): Tested-by: Krzysztof Kozlowski Acked-by: Oleksij Rempel Cc: stable@vger.kernel.org # Requires trivial backporting, simple remove # the 3rd argument from the calls to # i2c_imx_bus_busy(). Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit e385ea09b2e801cef1509e06bc691597aac80a99 Author: Christian Eggers Date: Fri Oct 9 13:03:19 2020 +0200 i2c: imx: Check for I2SR_IAL after every byte commit 1de67a3dee7a279ebe4d892b359fe3696938ec15 upstream. Arbitration Lost (IAL) can happen after every single byte transfer. If arbitration is lost, the I2C hardware will autonomously switch from master mode to slave. If a transfer is not aborted in this state, consecutive transfers will not be executed by the hardware and will timeout. Signed-off-by: Christian Eggers Tested (not extensively) on Vybrid VF500 (Toradex VF50): Tested-by: Krzysztof Kozlowski Acked-by: Oleksij Rempel Cc: stable@vger.kernel.org Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 12b2af654bac6ee44c751ee4fcb28cfd78e22ccb Author: Christian Eggers Date: Fri Oct 9 13:03:18 2020 +0200 i2c: imx: Fix reset of I2SR_IAL flag commit 384a9565f70a876c2e78e58c5ca0bbf0547e4f6d upstream. According to the "VFxxx Controller Reference Manual" (and the comment block starting at line 97), Vybrid requires writing a one for clearing an interrupt flag. Syncing the method for clearing I2SR_IIF in i2c_imx_isr(). Signed-off-by: Christian Eggers Fixes: 4b775022f6fd ("i2c: imx: add struct to hold more configurable quirks") Reviewed-by: Uwe Kleine-König Acked-by: Oleksij Rempel Cc: stable@vger.kernel.org Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit f3f39e9137072f6bf539437add7364f7615a772e Author: Alexander Gordeev Date: Thu Nov 26 18:00:37 2020 +0100 s390/pci: fix CPU address in MSI for directed IRQ commit a2bd4097b3ec242f4de4924db463a9c94530e03a upstream. The directed MSIs are delivered to CPUs whose address is written to the MSI message address. The current code assumes that a CPU logical number (as it is seen by the kernel) is also the CPU address. The above assumption is not correct, as the CPU address is rather the value returned by STAP instruction. That value does not necessarily match the kernel logical CPU number. Fixes: e979ce7bced2 ("s390/pci: provide support for CPU directed interrupts") Cc: # v5.2+ Signed-off-by: Alexander Gordeev Reviewed-by: Halil Pasic Reviewed-by: Niklas Schnelle Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 651b1f3cee421367ca3827cdf50d364cbb10bad0 Author: Andreas Gruenbacher Date: Mon Nov 30 16:07:25 2020 +0100 gfs2: Fix deadlock between gfs2_{create_inode,inode_lookup} and delete_work_func commit dd0ecf544125639e54056d851e4887dbb94b6d2f upstream. In gfs2_create_inode and gfs2_inode_lookup, make sure to cancel any pending delete work before taking the inode glock. Otherwise, gfs2_cancel_delete_work may block waiting for delete_work_func to complete, and delete_work_func may block trying to acquire the inode glock in gfs2_inode_lookup. Reported-by: Alexander Aring Fixes: a0e3cc65fa29 ("gfs2: Turn gl_delete into a delayed work") Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 8a208228d2796abb1c38d7cecb7fd485107d751d Author: Andreas Gruenbacher Date: Wed Nov 25 23:37:18 2020 +0100 gfs2: Upgrade shared glocks for atime updates commit 82e938bd5382b322ce81e6cb8fd030987f2da022 upstream. Commit 20f829999c38 ("gfs2: Rework read and page fault locking") lifted the glock lock taking from the low-level ->readpage and ->readahead address space operations to the higher-level ->read_iter file and ->fault vm operations. The glocks are still taken in LM_ST_SHARED mode only. On filesystems mounted without the noatime option, ->read_iter sometimes needs to update the atime as well, though. Right now, this leads to a failed locking mode assertion in gfs2_dirty_inode. Fix that by introducing a new update_time inode operation. There, if the glock is held non-exclusively, upgrade it to an exclusive lock. Reported-by: Alexander Aring Fixes: 20f829999c38 ("gfs2: Rework read and page fault locking") Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 7ab2621b2ff6766ece20140aeb1da13175107e0a Author: Aurelien Aptel Date: Thu Dec 3 19:46:08 2020 +0100 cifs: add NULL check for ses->tcon_ipc commit 59463eb88829f646aed13283fd84d02a475334fe upstream. In some scenarios (DFS and BAD_NETWORK_NAME) set_root_set() can be called with a NULL ses->tcon_ipc. Signed-off-by: Aurelien Aptel Reviewed-by: Paulo Alcantara (SUSE) CC: Stable Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 21ba03ff5aee160f66f7a595c2e99e4f23a20243 Author: Ronnie Sahlberg Date: Mon Nov 30 11:29:20 2020 +1000 cifs: refactor create_sd_buf() and and avoid corrupting the buffer commit ea64370bcae126a88cd26a16f1abcc23ab2b9a55 upstream. When mounting with "idsfromsid" mount option, Azure corrupted the owner SIDs due to excessive padding caused by placing the owner fields at the end of the security descriptor on create. Placing owners at the front of the security descriptor (rather than the end) is also safer, as the number of ACEs (that follow it) are variable. Signed-off-by: Ronnie Sahlberg Suggested-by: Rohith Surabattula CC: Stable # v5.8 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 08a257a3ff0c3947b5d8de06588a148d2ec2bcc2 Author: Paulo Alcantara Date: Sat Nov 28 16:54:02 2020 -0300 cifs: fix potential use-after-free in cifs_echo_request() commit 212253367dc7b49ed3fc194ce71b0992eacaecf2 upstream. This patch fixes a potential use-after-free bug in cifs_echo_request(). For instance, thread 1 -------- cifs_demultiplex_thread() clean_demultiplex_info() kfree(server) thread 2 (workqueue) -------- apic_timer_interrupt() smp_apic_timer_interrupt() irq_exit() __do_softirq() run_timer_softirq() call_timer_fn() cifs_echo_request() <- use-after-free in server ptr Signed-off-by: Paulo Alcantara (SUSE) CC: Stable Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 60729f2188ec6df45461451a4cf5a109d2cc1173 Author: Paulo Alcantara Date: Sat Nov 28 15:57:06 2020 -0300 cifs: allow syscalls to be restarted in __smb_send_rqst() commit 6988a619f5b79e4efadea6e19dcfe75fbcd350b5 upstream. A customer has reported that several files in their multi-threaded app were left with size of 0 because most of the read(2) calls returned -EINTR and they assumed no bytes were read. Obviously, they could have fixed it by simply retrying on -EINTR. We noticed that most of the -EINTR on read(2) were due to real-time signals sent by glibc to process wide credential changes (SIGRT_1), and its signal handler had been established with SA_RESTART, in which case those calls could have been automatically restarted by the kernel. Let the kernel decide to whether or not restart the syscalls when there is a signal pending in __smb_send_rqst() by returning -ERESTARTSYS. If it can't, it will return -EINTR anyway. Signed-off-by: Paulo Alcantara (SUSE) CC: Stable Reviewed-by: Ronnie Sahlberg Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit cd6bd84b19ac9d9cfd3c48eb8425f1dfabbb607a Author: Naveen N. Rao Date: Thu Nov 26 23:38:39 2020 +0530 ftrace: Fix DYNAMIC_FTRACE_WITH_DIRECT_CALLS dependency commit 49a962c075dfa41c78e34784772329bc8784d217 upstream. DYNAMIC_FTRACE_WITH_DIRECT_CALLS should depend on DYNAMIC_FTRACE_WITH_REGS since we need ftrace_regs_caller(). Link: https://lkml.kernel.org/r/fc4b257ea8689a36f086d2389a9ed989496ca63a.1606412433.git.naveen.n.rao@linux.vnet.ibm.com Cc: stable@vger.kernel.org Fixes: 763e34e74bb7d5c ("ftrace: Add register_ftrace_direct()") Signed-off-by: Naveen N. Rao Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 009b4bd377a92c32ef76223a15727037af3ded9c Author: Naveen N. Rao Date: Thu Nov 26 23:38:38 2020 +0530 ftrace: Fix updating FTRACE_FL_TRAMP commit 4c75b0ff4e4bf7a45b5aef9639799719c28d0073 upstream. On powerpc, kprobe-direct.tc triggered FTRACE_WARN_ON() in ftrace_get_addr_new() followed by the below message: Bad trampoline accounting at: 000000004222522f (wake_up_process+0xc/0x20) (f0000001) The set of steps leading to this involved: - modprobe ftrace-direct-too - enable_probe - modprobe ftrace-direct - rmmod ftrace-direct <-- trigger The problem turned out to be that we were not updating flags in the ftrace record properly. From the above message about the trampoline accounting being bad, it can be seen that the ftrace record still has FTRACE_FL_TRAMP set though ftrace-direct module is going away. This happens because we are checking if any ftrace_ops has the FTRACE_FL_TRAMP flag set _before_ updating the filter hash. The fix for this is to look for any _other_ ftrace_ops that also needs FTRACE_FL_TRAMP. Link: https://lkml.kernel.org/r/56c113aa9c3e10c19144a36d9684c7882bf09af5.1606412433.git.naveen.n.rao@linux.vnet.ibm.com Cc: stable@vger.kernel.org Fixes: a124692b698b0 ("ftrace: Enable trampoline when rec count returns back to one") Signed-off-by: Naveen N. Rao Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 5b158d047fe6b7f3ccca36fc077ea653da527dca Author: Steven Rostedt (VMware) Date: Mon Nov 30 23:16:03 2020 -0500 ring-buffer: Always check to put back before stamp when crossing pages commit 68e10d5ff512b503dcba1246ad5620f32035e135 upstream. The current ring buffer logic checks to see if the updating of the event buffer was interrupted, and if it is, it will try to fix up the before stamp with the write stamp to make them equal again. This logic is flawed, because if it is not interrupted, the two are guaranteed to be different, as the current event just updated the before stamp before allocation. This guarantees that the next event (this one or another interrupting one) will think it interrupted the time updates of a previous event and inject an absolute time stamp to compensate. The correct logic is to always update the timestamps when traversing to a new sub buffer. Cc: stable@vger.kernel.org Fixes: a389d86f7fd09 ("ring-buffer: Have nested events still record running time stamp") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 68e17e0b384c1cf6355591fcc2d1be003fc31a86 Author: Andrea Righi Date: Sat Nov 28 10:15:17 2020 +0100 ring-buffer: Set the right timestamp in the slow path of __rb_reserve_next() commit 8785f51a17083eee7c37606079c6447afc6ba102 upstream. In the slow path of __rb_reserve_next() a nested event(s) can happen between evaluating the timestamp delta of the current event and updating write_stamp via local_cmpxchg(); in this case the delta is not valid anymore and it should be set to 0 (same timestamp as the interrupting event), since the event that we are currently processing is not the last event in the buffer. Link: https://lkml.kernel.org/r/X8IVJcp1gRE+FJCJ@xps-13-7390 Cc: Ingo Molnar Cc: Masami Hiramatsu Cc: stable@vger.kernel.org Link: https://lwn.net/Articles/831207 Fixes: a389d86f7fd0 ("ring-buffer: Have nested events still record running time stamp") Signed-off-by: Andrea Righi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit fd3a46f25bb4ffc1f80fe1925a031a82982aeb14 Author: Steven Rostedt (VMware) Date: Fri Nov 27 11:20:58 2020 -0500 ring-buffer: Update write stamp with the correct ts commit 55ea4cf403800af2ce6b125bc3d853117e0c0456 upstream. The write stamp, used to calculate deltas between events, was updated with the stale "ts" value in the "info" structure, and not with the updated "ts" variable. This caused the deltas between events to be inaccurate, and when crossing into a new sub buffer, had time go backwards. Link: https://lkml.kernel.org/r/20201124223917.795844-1-elavila@google.com Cc: stable@vger.kernel.org Fixes: a389d86f7fd09 ("ring-buffer: Have nested events still record running time stamp") Reported-by: "J. Avila" Tested-by: Daniel Mentz Tested-by: Will McVicker Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 3555ab3552621852d89707b0f9cab7c5c27f8786 Author: Takashi Iwai Date: Fri Nov 27 15:11:03 2020 +0100 ALSA: hda/generic: Add option to enforce preferred_dacs pairs commit 242d990c158d5b1dabd166516e21992baef5f26a upstream. The generic parser accepts the preferred_dacs[] pairs as a hint for assigning a DAC to each pin, but this hint doesn't work always effectively. Currently it's merely a secondary choice after the trial with the path index failed. This made sometimes it difficult to assign DACs without mimicking the connection list and/or the badness table. This patch adds a new flag, obey_preferred_dacs, that changes the behavior of the parser. As its name stands, the parser obeys the given preferred_dacs[] pairs by skipping the path index matching and giving a high penalty if no DAC is assigned by the pairs. This mode will help for assigning the fixed DACs forcibly from the codec driver. Cc: Link: https://lore.kernel.org/r/20201127141104.11041-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3bdd3fbe7b57864696b7e79ba6ec6bcaff14d2c0 Author: Kailang Yang Date: Thu Nov 19 17:04:21 2020 +0800 ALSA: hda/realtek - Fixed Dell AIO wrong sound tone commit 92666d45adcfd4a4a70580ff9f732309e16131f9 upstream. This platform only had one audio jack. If it plugged speaker then replug with speaker or headset, the sound tone will change to abnormal. Headset Mic also can't record when this issue was happen. [ Added a short comment about the COEF by tiwai ] Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/593c777dcfef4546aa050e105b8e53b5@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 28a77b5db771148a9f403e9a8332474eaca816e9 Author: Kailang Yang Date: Fri Nov 27 14:39:23 2020 +0800 ALSA: hda/realtek - Add new codec supported for ALC897 commit e5782a5d5054bf1e03cb7fbd87035037c2a22698 upstream. Enable new codec supported for ALC897. Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/3b00520f304842aab8291eb8d9191bd8@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e8edaac826ba958856f9d4838302cdd755a14011 Author: Jian-Hong Pan Date: Tue Nov 24 17:20:25 2020 +0800 ALSA: hda/realtek: Enable headset of ASUS UX482EG & B9400CEA with ALC294 commit eeacd80fcb29b769ea915cd06b7dd35e0bf0bc25 upstream. Some laptops like ASUS UX482EG & B9400CEA's headset audio does not work until the quirk ALC294_FIXUP_ASUS_HPE is applied. Signed-off-by: Jian-Hong Pan Cc: Link: https://lore.kernel.org/r/20201124092024.179540-1-jhp@endlessos.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e3d9419b8f98f16014e86f80dc757d19c476dcac Author: Takashi Iwai Date: Sat Nov 28 10:00:15 2020 +0100 ALSA: hda/realtek: Add mute LED quirk to yet another HP x360 model commit aeedad2504997be262c98f6e3228173225a8d868 upstream. HP Spectre x360 Convertible 15" version (SSID 103c:827f) needs the same quirk to make the mute LED working like other models. System Information Manufacturer: HP Product Name: HP Spectre x360 Convertible 15-bl1XX Sound Codec: Codec: Realtek ALC295 Vendor Id: 0x10ec0295 Subsystem Id: 0x103c827f Revision Id: 0x100002 Reported-by: Cc: Link: https://lore.kernel.org/r/20201128090015.7743-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a5e4d94b74f93b66252798ca08f6fdb0a4240268 Author: Takashi Iwai Date: Fri Nov 27 15:11:04 2020 +0100 ALSA: hda/realtek: Fix bass speaker DAC assignment on Asus Zephyrus G14 commit c84bfedce60192c08455ee2d25dd13d19274a266 upstream. ASUS Zephyrus G14 has two speaker pins, and the auto-parser tries to assign an individual DAC to each pin as much as possible. Unfortunately the third DAC has no volume control unlike the two DACs, and this resulted in the inconsistent speaker volumes. As a workaround, wire both speaker pins to the same DAC by modifying the existing quirk (ALC289_FIXUP_ASUS_GA401) applied to this device. Since this quirk entry is chained by another, we need to avoid applying the DAC assignment change for it. Luckily, there is another quirk entry (ALC289_FIXUP_ASUS_GA502) doing the very same thing, so we can chain to the GA502 quirk instead. Note that this patch uses a new flag of the generic parser, obey_preferred_dacs, for enforcing the DACs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210359 Cc: Link: https://lore.kernel.org/r/20201127141104.11041-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9920472eaa7c652c7abcad4911fa83b6ae5a4955 Author: Samuel Thibault Date: Sun Nov 29 20:35:23 2020 +0100 speakup: Reject setting the speakup line discipline outside of speakup commit f0992098cadb4c9c6a00703b66cafe604e178fea upstream. Speakup exposing a line discipline allows userland to try to use it, while it is deemed to be useless, and thus uselessly exposes potential bugs. One of them is simply that in such a case if the line sends data, spk_ttyio_receive_buf2 is called and crashes since spk_ttyio_synth is NULL. This change restricts the use of the speakup line discipline to speakup drivers, thus avoiding such kind of issues altogether. Cc: stable@vger.kernel.org Reported-by: Shisong Qin Signed-off-by: Samuel Thibault Tested-by: Shisong Qin Link: https://lore.kernel.org/r/20201129193523.hm3f6n5xrn6fiyyc@function Signed-off-by: Greg Kroah-Hartman commit 730649666353d495cfa8eade6e7f57936d0466af Author: Jann Horn Date: Thu Dec 3 02:25:05 2020 +0100 tty: Fix ->session locking commit c8bcd9c5be24fb9e6132e97da5a35e55a83e36b9 upstream. Currently, locking of ->session is very inconsistent; most places protect it using the legacy tty mutex, but disassociate_ctty(), __do_SAK(), tiocspgrp() and tiocgsid() don't. Two of the writers hold the ctrl_lock (because they already need it for ->pgrp), but __proc_set_tty() doesn't do that yet. On a PREEMPT=y system, an unprivileged user can theoretically abuse this broken locking to read 4 bytes of freed memory via TIOCGSID if tiocgsid() is preempted long enough at the right point. (Other things might also go wrong, especially if root-only ioctls are involved; I'm not sure about that.) Change the locking on ->session such that: - tty_lock() is held by all writers: By making disassociate_ctty() hold it. This should be fine because the same lock can already be taken through the call to tty_vhangup_session(). The tricky part is that we need to shorten the area covered by siglock to be able to take tty_lock() without ugly retry logic; as far as I can tell, this should be fine, since nothing in the signal_struct is touched in the `if (tty)` branch. - ctrl_lock is held by all writers: By changing __proc_set_tty() to hold the lock a little longer. - All readers that aren't holding tty_lock() hold ctrl_lock: By adding locking to tiocgsid() and __do_SAK(), and expanding the area covered by ctrl_lock in tiocspgrp(). Cc: stable@kernel.org Signed-off-by: Jann Horn Reviewed-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 4203f474d4c3e93b3c2462e4f7954cf6e4832074 Author: Jann Horn Date: Thu Dec 3 02:25:04 2020 +0100 tty: Fix ->pgrp locking in tiocspgrp() commit 54ffccbf053b5b6ca4f6e45094b942fab92a25fc upstream. tiocspgrp() takes two tty_struct pointers: One to the tty that userspace passed to ioctl() (`tty`) and one to the TTY being changed (`real_tty`). These pointers are different when ioctl() is called with a master fd. To properly lock real_tty->pgrp, we must take real_tty->ctrl_lock. This bug makes it possible for racing ioctl(TIOCSPGRP, ...) calls on both sides of a PTY pair to corrupt the refcount of `struct pid`, leading to use-after-free errors. Fixes: 47f86834bbd4 ("redo locking of tty->pgrp") CC: stable@kernel.org Signed-off-by: Jann Horn Reviewed-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 1c07c7f0d913ee99b3cfa94bea33f353d4508d57 Author: Bjørn Mork Date: Tue Dec 1 11:03:18 2020 +0100 USB: serial: option: fix Quectel BG96 matching commit c98fff7332dbd6e028969f8c2bda3d7bc7a024d8 upstream. This is a partial revert of commit 2bb70f0a4b23 ("USB: serial: option: support dynamic Quectel USB compositions") The Quectel BG96 is different from most other modern Quectel modems, having serial functions with 3 endpoints using ff/ff/ff and ff/fe/ff class/subclass/protocol. Including it in the change to accommodate dynamic function mapping was incorrect. Revert to interface number matching for the BG96, assuming static layout of the RMNET function on interface 4. This restores support for the serial functions on interfaces 2 and 3. Full lsusb output for the BG96: Bus 002 Device 003: ID 2c7c:0296 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2c7c idProduct 0x0296 bcdDevice 0.00 iManufacturer 3 Qualcomm, Incorporated iProduct 2 Qualcomm CDMA Technologies MSM iSerial 4 d1098243 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 145 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 1 Qualcomm Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 254 bInterfaceProtocol 255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Cc: Sebastian Sjoholm Fixes: 2bb70f0a4b23 ("USB: serial: option: support dynamic Quectel USB compositions") Signed-off-by: Bjørn Mork Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3a02b029501b4b8d8ef5d69ead99983da90fbb69 Author: Giacinto Cifelli Date: Wed Nov 25 15:53:04 2020 +0100 USB: serial: option: add support for Thales Cinterion EXS82 commit 6d6556c04ebaeaf4e7fa8b791c97e2a7c41b38a3 upstream. There is a single option port in this modem, and it is used as debug port. lsusb -v for this device: Bus 001 Device 002: ID 1e2d:006c Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1e2d idProduct 0x006c bcdDevice 0.00 iManufacturer 4 iProduct 3 iSerial 5 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 243 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 2 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 1 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 2 CDC Union: bMasterInterface 1 bSlaveInterface 2 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 3 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 4 CDC Union: bMasterInterface 3 bSlaveInterface 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 5 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 0 CDC Header: bcdCDC 1.10 CDC Ethernet: iMacAddress 1 (??) bmEthernetStatistics 0x00000000 wMaxSegmentSize 16384 wNumberMCFilters 0x0001 bNumberPowerFilters 0 CDC Union: bMasterInterface 5 bSlaveInterface 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Signed-off-by: Giacinto Cifelli Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 80765816027c684031c69b6a11393c05c4e4c4ea Author: Vincent Palatin Date: Fri Nov 20 10:28:28 2020 +0100 USB: serial: option: add Fibocom NL668 variants commit 5e4d659b10fde14403adb2e215df4a3168fe8465 upstream. Update the USB serial option driver support for the Fibocom NL668 Cat.4 LTE modules as there are actually several different variants. Got clarifications from Fibocom, there are distinct products: - VID:PID 1508:1001, NL668 for IOT (no MBIM interface) - VID:PID 2cb7:01a0, NL668-AM and NL652-EU are laptop M.2 cards (with MBIM interfaces for Windows/Linux/Chrome OS), respectively for Americas and Europe. usb-devices output for the laptop M.2 cards: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2cb7 ProdID=01a0 Rev=03.18 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom NL652-EU Modem S: SerialNumber=0123456789ABCDEF C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by: Vincent Palatin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3e1196c0a5f6797d3e5d68e123c9de2307423465 Author: Johan Hovold Date: Thu Dec 3 10:11:59 2020 +0100 USB: serial: ch341: sort device-id entries commit bf193bfc12dbc3754fc8a6e0e1e3702f1af2f772 upstream. Keep the device-id entries sorted to make it easier to add new ones in the right spot. Reviewed-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 5c80adb06ce9defea2c4bccd7446a17971cb1d7d Author: Jan-Niklas Burfeind Date: Thu Dec 3 04:03:59 2020 +0100 USB: serial: ch341: add new Product ID for CH341A commit 46ee4abb10a07bd8f8ce910ee6b4ae6a947d7f63 upstream. Add PID for CH340 that's found on a ch341 based Programmer made by keeyees. The specific device that contains the serial converter is described here: http://www.keeyees.com/a/Products/ej/36.html The driver works flawlessly as soon as the new PID (0x5512) is added to it. Signed-off-by: Jan-Niklas Burfeind Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9c6ceecfcf6d445f4d17afa9519a6d051e070685 Author: Johan Hovold Date: Fri Dec 4 09:55:19 2020 +0100 USB: serial: kl5kusb105: fix memleak on open commit 3f203f057edfcf6bd02c6b942799262bfcf31f73 upstream. Fix memory leak of control-message transfer buffer on successful open(). Fixes: 6774d5f53271 ("USB: serial: kl5kusb105: fix open error path") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1407da34fe434da473bed205c80ea50480712af8 Author: Vamsi Krishna Samavedam Date: Mon Nov 30 12:34:53 2020 -0800 usb: gadget: f_fs: Use local copy of descriptors for userspace copy commit a4b98a7512f18534ce33a7e98e49115af59ffa00 upstream. The function may be unbound causing the ffs_ep and its descriptors to be freed while userspace is in the middle of an ioctl requesting the same descriptors. Avoid dangling pointer reference by first making a local copy of desctiptors before releasing the spinlock. Fixes: c559a3534109 ("usb: gadget: f_fs: add ioctl returning ep descriptor") Reviewed-by: Peter Chen Signed-off-by: Vamsi Krishna Samavedam Signed-off-by: Jack Pham Cc: stable Link: https://lore.kernel.org/r/20201130203453.28154-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 4d5bf3938642738c2b28067199ed3ffe3fb84ecb Author: Alexandre Frade Date: Tue Dec 8 21:10:14 2020 +0000 Linux 5.9.13-xanmod2 Signed-off-by: Alexandre Frade commit 68071465c0f3d353f1807170af9fd3fc03c2b245 Author: Alexandre Frade Date: Tue Dec 8 14:15:31 2020 +0000 Linux 5.9.13-xanmod1 Signed-off-by: Alexandre Frade commit b5718414089e5dbab6949d5bcfacc4574a38b611 Merge: 82ef34df18e4 90daeb0fbf64 Author: Alexandre Frade Date: Tue Dec 8 14:13:05 2020 +0000 Merge tag 'v5.9.13' into 5.9 This is the 5.9.13 stable release commit 90daeb0fbf6497334e3ad3098b0a1c72f44d8716 Author: Greg Kroah-Hartman Date: Tue Dec 8 10:42:05 2020 +0100 Linux 5.9.13 Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20201206111556.455533723@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 166dfd3ba5a4c71815fddb247cb08fef2412bfb4 Author: Chris Wilson Date: Thu Oct 15 13:21:38 2020 +0100 drm/i915/gt: Fixup tgl mocs for PTE tracking commit be33805c65297611971003d72e7f9235e23ec84d upstream. Forcing mocs:1 [used for our winsys follows-pte mode] to be cached caused display glitches. Though it is documented as deprecated (and so likely behaves as uncached) use the follow-pte bit and force it out of L3 cache. Testcase: igt/kms_frontbuffer_tracking Testcase: igt/kms_big_fb Signed-off-by: Chris Wilson Cc: Ayaz A Siddiqui Cc: Lucas De Marchi Cc: Matt Roper Cc: Ville Syrjälä Cc: Joonas Lahtinen Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20201015122138.30161-4-chris@chris-wilson.co.uk (cherry picked from commit a04ac827366594c7244f60e9be79fcb404af69f0) Fixes: 849c0fe9e831 ("drm/i915/gt: Initialize reserved and unspecified MOCS indices") Signed-off-by: Rodrigo Vivi [Rodrigo: Updated Fixes tag] Signed-off-by: Greg Kroah-Hartman commit 029de834c8674a078a97c51f12da4633a8a7d606 Author: Eric Sandeen Date: Tue Dec 1 17:21:40 2020 -0600 uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT commit 72d1249e2ffdbc344e465031ec5335fa3489d62e upstream. STATX_ATTR_MOUNT_ROOT and STATX_ATTR_DAX got merged with the same value, so one of them needs fixing. Move STATX_ATTR_DAX. While we're in here, clarify the value-matching scheme for some of the attributes, and explain why the value for DAX does not match. Fixes: 80340fe3605c ("statx: add mount_root") Fixes: 712b2698e4c0 ("fs/stat: Define DAX statx attribute") Link: https://lore.kernel.org/linux-fsdevel/7027520f-7c79-087e-1d00-743bdefa1a1e@redhat.com/ Link: https://lore.kernel.org/lkml/20201202214629.1563760-1-ira.weiny@intel.com/ Reported-by: David Howells Signed-off-by: Eric Sandeen Reviewed-by: David Howells Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Ira Weiny Cc: # 5.8 Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9d8888e397fec01a3517a84eba06db1b486bb048 Author: Vasily Averin Date: Wed Nov 18 15:05:20 2020 +0300 tracing: Remove WARN_ON in start_thread() commit 310e3a4b5a4fc718a72201c1e4cf5c64ac6f5442 upstream. This patch reverts commit 978defee11a5 ("tracing: Do a WARN_ON() if start_thread() in hwlat is called when thread exists") .start hook can be legally called several times if according tracer is stopped screen window 1 [root@localhost ~]# echo 1 > /sys/kernel/tracing/events/kmem/kfree/enable [root@localhost ~]# echo 1 > /sys/kernel/tracing/options/pause-on-trace [root@localhost ~]# less -F /sys/kernel/tracing/trace screen window 2 [root@localhost ~]# cat /sys/kernel/debug/tracing/tracing_on 0 [root@localhost ~]# echo hwlat > /sys/kernel/debug/tracing/current_tracer [root@localhost ~]# echo 1 > /sys/kernel/debug/tracing/tracing_on [root@localhost ~]# cat /sys/kernel/debug/tracing/tracing_on 0 [root@localhost ~]# echo 2 > /sys/kernel/debug/tracing/tracing_on triggers warning in dmesg: WARNING: CPU: 3 PID: 1403 at kernel/trace/trace_hwlat.c:371 hwlat_tracer_start+0xc9/0xd0 Link: https://lkml.kernel.org/r/bd4d3e70-400d-9c82-7b73-a2d695e86b58@virtuozzo.com Cc: Ingo Molnar Cc: stable@vger.kernel.org Fixes: 978defee11a5 ("tracing: Do a WARN_ON() if start_thread() in hwlat is called when thread exists") Signed-off-by: Vasily Averin Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit e159ec268afcb7f0d83c231b8cab6fcfd1508324 Author: Minchan Kim Date: Wed Nov 25 14:56:54 2020 -0800 tracing: Fix alignment of static buffer commit 8fa655a3a0013a0c2a2aada6f39a93ee6fc25549 upstream. With 5.9 kernel on ARM64, I found ftrace_dump output was broken but it had no problem with normal output "cat /sys/kernel/debug/tracing/trace". With investigation, it seems coping the data into temporal buffer seems to break the align binary printf expects if the static buffer is not aligned with 4-byte. IIUC, get_arg in bstr_printf expects that args has already right align to be decoded and seq_buf_bprintf says ``the arguments are saved in a 32bit word array that is defined by the format string constraints``. So if we don't keep the align under copy to temporal buffer, the output will be broken by shifting some bytes. This patch fixes it. Link: https://lkml.kernel.org/r/20201125225654.1618966-1-minchan@kernel.org Cc: Fixes: 8e99cf91b99bb ("tracing: Do not allocate buffer in trace_find_next_entry() in atomic") Signed-off-by: Namhyung Kim Signed-off-by: Minchan Kim Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit acf7d3a5028f2faaeb7ad44bcc4d93e3967c40c4 Author: Linus Walleij Date: Tue Dec 1 09:55:29 2020 -0800 Input: atmel_mxt_ts - fix lost interrupts commit 8c3b55a299c325830a987de21dab6a89ecb71164 upstream. After commit 74d905d2d38a devices requiring the workaround for edge triggered interrupts stopped working. The hardware needs the quirk to be used before even proceeding to check if the quirk is needed because mxt_acquire_irq() is called before mxt_check_retrigen() is called and at this point pending IRQs need to be checked, and if the workaround is not active, all interrupts will be lost from this point. Solve this by switching the calls around. Reported-by: Andre Müller Tested-by: Andre Müller Suggested-by: Dmitry Torokhov Fixes: 74d905d2d38a ("Input: atmel_mxt_ts - only read messages in mxt_acquire_irq() when necessary") Signed-off-by: Linus Walleij Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201201123026.1416743-1-linus.walleij@linaro.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 27a940251c95fc755920596905d64d0d6866409c Author: Po-Hsu Lin Date: Mon Nov 30 22:39:40 2020 -0800 Input: i8042 - add ByteSpeed touchpad to noloop table commit a48491c65b513e5cdc3e7a886a4db915f848a5f5 upstream. It looks like the C15B laptop got another vendor: ByteSpeed LLC. Avoid AUX loopback on this touchpad as well, thus input subsystem will be able to recognize a Synaptics touchpad in the AUX port. BugLink: https://bugs.launchpad.net/bugs/1906128 Signed-off-by: Po-Hsu Lin Link: https://lore.kernel.org/r/20201201054723.5939-1-po-hsu.lin@canonical.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c61460856af950b847a8bf015482d914f0bb9489 Author: Sanjay Govind Date: Mon Nov 30 23:41:48 2020 -0800 Input: xpad - support Ardwiino Controllers commit 2aab1561439032be2e98811dd0ddbeb5b2ae4c61 upstream. This commit adds support for Ardwiino Controllers Signed-off-by: Sanjay Govind Link: https://lore.kernel.org/r/20201201071922.131666-1-sanjay.govind9@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 79891b6859b1fe8c8199bebbb704aaf4556481c7 Author: Hector Martin Date: Fri Nov 27 22:26:35 2020 +0900 ALSA: usb-audio: US16x08: fix value count for level meters commit 402d5840b0d40a2a26c8651165d29b534abb6d36 upstream. The level meter control returns 34 integers of info. This fixes: snd-usb-audio 3-1:1.0: control 2:0:0:Level Meter:0: access overflow Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk") Cc: stable@vger.kernel.org Signed-off-by: Hector Martin Link: https://lore.kernel.org/r/20201127132635.18947-1-marcan@marcan.st Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 44e05a398db7997dc457157d899fadd0880526d2 Author: Randy Dunlap Date: Wed Dec 2 20:39:44 2020 -0800 net: mlx5e: fix fs_tcp.c build when IPV6 is not enabled [ Upstream commit 8a78a440108e55ddd845b0ef46df575248667520 ] Fix build when CONFIG_IPV6 is not enabled by making a function be built conditionally. Fixes these build errors and warnings: ../drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c: In function 'accel_fs_tcp_set_ipv6_flow': ../include/net/sock.h:380:34: error: 'struct sock_common' has no member named 'skc_v6_daddr'; did you mean 'skc_daddr'? 380 | #define sk_v6_daddr __sk_common.skc_v6_daddr | ^~~~~~~~~~~~ ../drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c:55:14: note: in expansion of macro 'sk_v6_daddr' 55 | &sk->sk_v6_daddr, 16); | ^~~~~~~~~~~ At top level: ../drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c:47:13: warning: 'accel_fs_tcp_set_ipv6_flow' defined but not used [-Wunused-function] 47 | static void accel_fs_tcp_set_ipv6_flow(struct mlx5_flow_spec *spec, struct sock *sk) Fixes: 5229a96e59ec ("net/mlx5e: Accel, Expose flow steering API for rules add/del") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Signed-off-by: Saeed Mahameed Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2bbf44876dbf6402988bf5d48fdca281e3ee3579 Author: Eran Ben Elisha Date: Wed Dec 2 20:39:43 2020 -0800 net/mlx5: Fix wrong address reclaim when command interface is down [ Upstream commit 1d2bb5ad89f47d8ce8aedc70ef85059ab3870292 ] When command interface is down, driver to reclaim all 4K page chucks that were hold by the Firmeware. Fix a bug for 64K page size systems, where driver repeatedly released only the first chunk of the page. Define helper function to fill 4K chunks for a given Firmware pages. Iterate over all unreleased Firmware pages and call the hepler per each. Fixes: 5adff6a08862 ("net/mlx5: Fix incorrect page count when in internal error") Signed-off-by: Eran Ben Elisha Signed-off-by: Saeed Mahameed Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit db7af1871e78e6da4f5f8cb76067319935995169 Author: Yevgeny Kliteynik Date: Wed Dec 2 20:39:46 2020 -0800 net/mlx5: DR, Proper handling of unsupported Connect-X6DX SW steering [ Upstream commit d421e466c2373095f165ddd25cbabd6c5b077928 ] STEs format for Connect-X5 and Connect-X6DX different. Currently, on Connext-X6DX the SW steering would break at some point when building STEs w/o giving a proper error message. Fix this by checking the STE format of the current device when initializing domain: add mlx5_ifc definitions for Connect-X6DX SW steering, read FW capability to get the current format version, and check this version when domain is being created. Fixes: 26d688e33f88 ("net/mlx5: DR, Add Steering entry (STE) utilities") Signed-off-by: Yevgeny Kliteynik Signed-off-by: Saeed Mahameed Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bcfeff6ec630b3837c67730675e8e343d73b48cc Author: Davide Caratti Date: Thu Dec 3 10:37:52 2020 +0100 net/sched: act_mpls: ensure LSE is pullable before reading it [ Upstream commit 9608fa653059c3f72faab0c148ac8773c46e7314 ] when 'act_mpls' is used to mangle the LSE, the current value is read from the packet dereferencing 4 bytes at mpls_hdr(): ensure that the label is contained in the skb "linear" area. Found by code inspection. v2: - use MPLS_HLEN instead of sizeof(new_lse), thanks to Jakub Kicinski Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC") Signed-off-by: Davide Caratti Acked-by: Guillaume Nault Link: https://lore.kernel.org/r/3243506cba43d14858f3bd21ee0994160e44d64a.1606987058.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 44a0f9f84d690d0c06e9a4c0c44d1f3760f00a61 Author: Davide Caratti Date: Thu Dec 3 10:46:06 2020 +0100 net: openvswitch: ensure LSE is pullable before reading it [ Upstream commit 43c13605bad44b8abbc9776d6e63f62ccb7a47d6 ] when openvswitch is configured to mangle the LSE, the current value is read from the packet dereferencing 4 bytes at mpls_hdr(): ensure that the label is contained in the skb "linear" area. Found by code inspection. Fixes: d27cf5c59a12 ("net: core: add MPLS update core helper and use in OvS") Signed-off-by: Davide Caratti Link: https://lore.kernel.org/r/aa099f245d93218b84b5c056b67b6058ccf81a66.1606987185.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b9ed9b689f534c9feea9f5ef8dff1ec4475ce439 Author: Davide Caratti Date: Thu Dec 3 10:58:21 2020 +0100 net: skbuff: ensure LSE is pullable before decrementing the MPLS ttl [ Upstream commit 13de4ed9e3a9ccbe54d05f7d5c773f69ecaf6c64 ] skb_mpls_dec_ttl() reads the LSE without ensuring that it is contained in the skb "linear" area. Fix this calling pskb_may_pull() before reading the current ttl. Found by code inspection. Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC") Reported-by: Marcelo Ricardo Leitner Signed-off-by: Davide Caratti Link: https://lore.kernel.org/r/53659f28be8bc336c113b5254dc637cc76bbae91.1606987074.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9e99b623ecbed292518c0fdbc7c101a79e79d578 Author: Wang Hai Date: Thu Dec 3 22:18:06 2020 +0800 net: mvpp2: Fix error return code in mvpp2_open() [ Upstream commit 82a10dc7f0960735f40e8d7d3bee56934291600f ] Fix to return negative error code -ENOENT from invalid configuration error handling case instead of 0, as done elsewhere in this function. Fixes: 4bb043262878 ("net: mvpp2: phylink support") Reported-by: Hulk Robot Signed-off-by: Wang Hai Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20201203141806.37966-1-wanghai38@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2f8a3f6b2d4bf255b3852beda8561a1e76fc2d22 Author: Dan Carpenter Date: Thu Dec 3 11:44:31 2020 +0300 chelsio/chtls: fix a double free in chtls_setkey() [ Upstream commit 391119fb5c5c4bdb4d57c7ffeb5e8d18560783d1 ] The "skb" is freed by the transmit code in cxgb4_ofld_send() and we shouldn't use it again. But in the current code, if we hit an error later on in the function then the clean up code will call kfree_skb(skb) and so it causes a double free. Set the "skb" to NULL and that makes the kfree_skb() a no-op. Fixes: d25f2f71f653 ("crypto: chtls - Program the TLS session Key") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/X8ilb6PtBRLWiSHp@mwanda Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1f8846e3fd6ac328ea492ff17e3afd26ba9d5b2f Author: Zhang Changzhong Date: Wed Dec 2 17:58:42 2020 +0800 vxlan: fix error return code in __vxlan_dev_create() [ Upstream commit 832e09798c261cf58de3a68cfcc6556408c16a5a ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level") Reported-by: Hulk Robot Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1606903122-2098-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b6f2d8c6e3cfd04218c50db10aef8dec27204359 Author: Zhang Changzhong Date: Wed Dec 2 17:57:15 2020 +0800 net: pasemi: fix error return code in pasemi_mac_open() [ Upstream commit aba84871bd4f52c4dfcf3ad5d4501a6c9d2de90e ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 72b05b9940f0 ("pasemi_mac: RX/TX ring management cleanup") Fixes: 8d636d8bc5ff ("pasemi_mac: jumbo frame support") Reported-by: Hulk Robot Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1606903035-1838-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6ff9e906d73df21fd89d6555c138944eb9e09a65 Author: Zhang Changzhong Date: Wed Dec 2 17:56:05 2020 +0800 cxgb3: fix error return code in t3_sge_alloc_qset() [ Upstream commit ff9924897f8bfed82e61894b373ab9d2dfea5b10 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: b1fb1f280d09 ("cxgb3 - Fix dma mapping error path") Reported-by: Hulk Robot Signed-off-by: Zhang Changzhong Acked-by: Raju Rangoju Link: https://lore.kernel.org/r/1606902965-1646-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7704d8bbcfb640e6cda0e48f6b4edfeac00426a9 Author: Dan Carpenter Date: Tue Dec 1 18:15:12 2020 +0300 net/x25: prevent a couple of overflows [ Upstream commit 6ee50c8e262a0f0693dad264c3c99e30e6442a56 ] The .x25_addr[] address comes from the user and is not necessarily NUL terminated. This leads to a couple problems. The first problem is that the strlen() in x25_bind() can read beyond the end of the buffer. The second problem is more subtle and could result in memory corruption. The call tree is: x25_connect() --> x25_write_internal() --> x25_addr_aton() The .x25_addr[] buffers are copied to the "addresses" buffer from x25_write_internal() so it will lead to stack corruption. Verify that the strings are NUL terminated and return -EINVAL if they are not. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: a9288525d2ae ("X25: Dont let x25_bind use addresses containing characters") Reported-by: "kiyin(尹亮)" Signed-off-by: Dan Carpenter Acked-by: Martin Schiller Link: https://lore.kernel.org/r/X8ZeAKm8FnFpN//B@mwanda Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6eb5ed2b5b9faba9e6f6f0f258685ed794627ba7 Author: Yangbo Lu Date: Tue Dec 1 15:52:58 2020 +0800 dpaa_eth: copy timestamp fields to new skb in A-050385 workaround [ Upstream commit 07500a6085806d97039ebcba8d9b8b29129f0106 ] The timestamp fields should be copied to new skb too in A-050385 workaround for later TX timestamping handling. Fixes: 3c68b8fffb48 ("dpaa_eth: FMan erratum A050385 workaround") Signed-off-by: Yangbo Lu Acked-by: Camelia Groza Link: https://lore.kernel.org/r/20201201075258.1875-1-yangbo.lu@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d9897bb66ce989325b4bf4cdbb6a799e4ac878b6 Author: Antoine Tenart Date: Mon Nov 30 17:19:11 2020 +0100 net: ip6_gre: set dev->hard_header_len when using header_ops [ Upstream commit 832ba596494b2c9eac7760259eff2d8b7dcad0ee ] syzkaller managed to crash the kernel using an NBMA ip6gre interface. I could reproduce it creating an NBMA ip6gre interface and forwarding traffic to it: skbuff: skb_under_panic: text:ffffffff8250e927 len:148 put:44 head:ffff8c03c7a33 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:109! Call Trace: skb_push+0x10/0x10 ip6gre_header+0x47/0x1b0 neigh_connected_output+0xae/0xf0 ip6gre tunnel provides its own header_ops->create, and sets it conditionally when initializing the tunnel in NBMA mode. When header_ops->create is used, dev->hard_header_len should reflect the length of the header created. Otherwise, when not used, dev->needed_headroom should be used. Fixes: eb95f52fc72d ("net: ipv6_gre: Fix GRO to work on IPv6 over GRE tap") Cc: Maria Pasechnik Signed-off-by: Antoine Tenart Link: https://lore.kernel.org/r/20201130161911.464106-1-atenart@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0d555687edf899528a202bbd7f497e9d4727a488 Author: Eric Dumazet Date: Tue Dec 1 01:05:07 2020 -0800 geneve: pull IP header before ECN decapsulation [ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ] IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume IP header is already pulled. geneve does not ensure this yet. Fixing this generically in IP_ECN_decapsulate() and IP6_ECN_decapsulate() is not possible, since callers pass a pointer that might be freed by pskb_may_pull() syzbot reported : BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:238 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate+0x345/0x1db0 include/net/inet_ecn.h:260 CPU: 1 PID: 8941 Comm: syz-executor.0 Not tainted 5.10.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 __INET_ECN_decapsulate include/net/inet_ecn.h:238 [inline] INET_ECN_decapsulate+0x345/0x1db0 include/net/inet_ecn.h:260 geneve_rx+0x2103/0x2980 include/net/inet_ecn.h:306 geneve_udp_encap_recv+0x105c/0x1340 drivers/net/geneve.c:377 udp_queue_rcv_one_skb+0x193a/0x1af0 net/ipv4/udp.c:2093 udp_queue_rcv_skb+0x282/0x1050 net/ipv4/udp.c:2167 udp_unicast_rcv_skb net/ipv4/udp.c:2325 [inline] __udp4_lib_rcv+0x399d/0x5880 net/ipv4/udp.c:2394 udp_rcv+0x5c/0x70 net/ipv4/udp.c:2564 ip_protocol_deliver_rcu+0x572/0xc50 net/ipv4/ip_input.c:204 ip_local_deliver_finish net/ipv4/ip_input.c:231 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip_local_deliver+0x583/0x8d0 net/ipv4/ip_input.c:252 dst_input include/net/dst.h:449 [inline] ip_rcv_finish net/ipv4/ip_input.c:428 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip_rcv+0x5c3/0x840 net/ipv4/ip_input.c:539 __netif_receive_skb_one_core net/core/dev.c:5315 [inline] __netif_receive_skb+0x1ec/0x640 net/core/dev.c:5429 process_backlog+0x523/0xc10 net/core/dev.c:6319 napi_poll+0x420/0x1010 net/core/dev.c:6763 net_rx_action+0x35c/0xd40 net/core/dev.c:6833 __do_softirq+0x1a9/0x6fa kernel/softirq.c:298 asm_call_irq_on_stack+0xf/0x20 __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline] do_softirq_own_stack+0x6e/0x90 arch/x86/kernel/irq_64.c:77 do_softirq kernel/softirq.c:343 [inline] __local_bh_enable_ip+0x184/0x1d0 kernel/softirq.c:195 local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32 rcu_read_unlock_bh include/linux/rcupdate.h:730 [inline] __dev_queue_xmit+0x3a9b/0x4520 net/core/dev.c:4167 dev_queue_xmit+0x4b/0x60 net/core/dev.c:4173 packet_snd net/packet/af_packet.c:2992 [inline] packet_sendmsg+0x86f9/0x99d0 net/packet/af_packet.c:3017 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] __sys_sendto+0x9dc/0xc80 net/socket.c:1992 __do_sys_sendto net/socket.c:2004 [inline] __se_sys_sendto+0x107/0x130 net/socket.c:2000 __x64_sys_sendto+0x6e/0x90 net/socket.c:2000 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 2d07dc79fe04 ("geneve: add initial netdev driver for GENEVE tunnels") Signed-off-by: Eric Dumazet Reported-by: syzbot Link: https://lore.kernel.org/r/20201201090507.4137906-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6e3e10fa7a15e256d0fbd813fa0b923a5bf2ad4a Author: Toke Høiland-Jørgensen Date: Mon Nov 30 19:37:05 2020 +0100 inet_ecn: Fix endianness of checksum update when setting ECT(1) [ Upstream commit 2867e1eac61016f59b3d730e3f7aa488e186e917 ] When adding support for propagating ECT(1) marking in IP headers it seems I suffered from endianness-confusion in the checksum update calculation: In fact the ECN field is in the *lower* bits of the first 16-bit word of the IP header when calculating in network byte order. This means that the addition performed to update the checksum field was wrong; let's fix that. Fixes: b723748750ec ("tunnel: Propagate ECT(1) when decapsulating as recommended by RFC6040") Reported-by: Jonathan Morton Tested-by: Pete Heist Signed-off-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/r/20201130183705.17540-1-toke@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ecaeeb4b5acbb37ad3343a69a2c3e50a8d346aea Author: Hoang Le Date: Mon Nov 30 09:55:44 2020 +0700 tipc: fix incompatible mtu of transmission [ Upstream commit 0643334902fcdc770e2d9555811200213339a3f6 ] In commit 682cd3cf946b6 ("tipc: confgiure and apply UDP bearer MTU on running links"), we introduced a function to change UDP bearer MTU and applied this new value across existing per-link. However, we did not apply this new MTU value at node level. This lead to packet dropped at link level if its size is greater than new MTU value. To fix this issue, we also apply this new MTU value for node level. Fixes: 682cd3cf946b6 ("tipc: confgiure and apply UDP bearer MTU on running links") Acked-by: Jon Maloy Signed-off-by: Hoang Le Link: https://lore.kernel.org/r/20201130025544.3602-1-hoang.h.le@dektech.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 80409f440fb4bd07b8a4c4386f346ec799252d9d Author: Thomas Falcon Date: Tue Dec 1 09:52:11 2020 -0600 ibmvnic: Fix TX completion error handling [ Upstream commit ba246c175116e2e8fa4fdfa5f8e958e086a9a818 ] TX completions received with an error return code are not being processed properly. When an error code is seen, do not proceed to the next completion before cleaning up the existing entry's data structures. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6db9f0c93f978a62c32124300cc01679093c2667 Author: Thomas Falcon Date: Tue Dec 1 09:52:10 2020 -0600 ibmvnic: Ensure that SCRQ entry reads are correctly ordered [ Upstream commit b71ec952234610b4f90ef17a2fdcb124d5320070 ] Ensure that received Subordinate Command-Response Queue (SCRQ) entries are properly read in order by the driver. These queues are used in the ibmvnic device to process RX buffer and TX completion descriptors. dma_rmb barriers have been added after checking for a pending descriptor to ensure the correct descriptor entry is checked and after reading the SCRQ descriptor to ensure the entire descriptor is read before processing. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5a0a5d6881a0dfb3e2d386ef00447107f37e489a Author: Vinay Kumar Yadav Date: Thu Nov 26 03:19:14 2020 +0530 chelsio/chtls: fix panic during unload reload chtls [ Upstream commit e3d5e971d2f83d8ddd4b91a50cea4517fb488383 ] there is kernel panic in inet_twsk_free() while chtls module unload when socket is in TIME_WAIT state because sk_prot_creator was not preserved on connection socket. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Udai Sharma Signed-off-by: Vinay Kumar Yadav Link: https://lore.kernel.org/r/20201125214913.16938-1-vinay.yadav@chelsio.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dab3f44c5fa84719d6e6eff8d31c6e478703ce56 Author: Krzysztof Kozlowski Date: Mon Oct 26 16:36:20 2020 +0100 dt-bindings: net: correct interrupt flags in examples [ Upstream commit 4d521943f76bd0d1e68ea5e02df7aadd30b2838a ] GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning: 1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE 2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING Correct the interrupt flags, assuming the author of the code wanted same logical behavior behind the name "ACTIVE_xxx", this is: ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW ACTIVE_HIGH => IRQ_TYPE_LEVEL_HIGH Fixes: a1a8b4594f8d ("NFC: pn544: i2c: Add DTS Documentation") Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver") Fixes: e3b329221567 ("dt-bindings: can: tcan4x5x: Update binding to use interrupt property") Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Acked-by: Marc Kleine-Budde # for tcan4x5x.txt Link: https://lore.kernel.org/r/20201026153620.89268-1-krzk@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f9309d52c9e2d5d8c8bf218d846be7869abccf5d Author: Guillaume Nault Date: Thu Nov 26 19:09:22 2020 +0100 ipv4: Fix tos mask in inet_rtm_getroute() [ Upstream commit 1ebf179037cb46c19da3a9c1e2ca16e7a754b75e ] When inet_rtm_getroute() was converted to use the RCU variants of ip_route_input() and ip_route_output_key(), the TOS parameters stopped being masked with IPTOS_RT_MASK before doing the route lookup. As a result, "ip route get" can return a different route than what would be used when sending real packets. For example: $ ip route add 192.0.2.11/32 dev eth0 $ ip route add unreachable 192.0.2.11/32 tos 2 $ ip route get 192.0.2.11 tos 2 RTNETLINK answers: No route to host But, packets with TOS 2 (ECT(0) if interpreted as an ECN bit) would actually be routed using the first route: $ ping -c 1 -Q 2 192.0.2.11 PING 192.0.2.11 (192.0.2.11) 56(84) bytes of data. 64 bytes from 192.0.2.11: icmp_seq=1 ttl=64 time=0.173 ms --- 192.0.2.11 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.173/0.173/0.173/0.000 ms This patch re-applies IPTOS_RT_MASK in inet_rtm_getroute(), to return results consistent with real route lookups. Fixes: 3765d35ed8b9 ("net: ipv4: Convert inet_rtm_getroute to rcu versions of route lookup") Signed-off-by: Guillaume Nault Reviewed-by: David Ahern Link: https://lore.kernel.org/r/b2d237d08317ca55926add9654a48409ac1b8f5b.1606412894.git.gnault@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 11152c46e4b71b75cc9f9cc14d393b9509444f11 Author: Antoine Tenart Date: Mon Nov 23 18:49:02 2020 +0100 netfilter: bridge: reset skb->pkt_type after NF_INET_POST_ROUTING traversal [ Upstream commit 44f64f23bae2f0fad25503bc7ab86cd08d04cd47 ] Netfilter changes PACKET_OTHERHOST to PACKET_HOST before invoking the hooks as, while it's an expected value for a bridge, routing expects PACKET_HOST. The change is undone later on after hook traversal. This can be seen with pairs of functions updating skb>pkt_type and then reverting it to its original value: For hook NF_INET_PRE_ROUTING: setup_pre_routing / br_nf_pre_routing_finish For hook NF_INET_FORWARD: br_nf_forward_ip / br_nf_forward_finish But the third case where netfilter does this, for hook NF_INET_POST_ROUTING, the packet type is changed in br_nf_post_routing but never reverted. A comment says: /* We assume any code from br_dev_queue_push_xmit onwards doesn't care * about the value of skb->pkt_type. */ But when having a tunnel (say vxlan) attached to a bridge we have the following call trace: br_nf_pre_routing br_nf_pre_routing_ipv6 br_nf_pre_routing_finish br_nf_forward_ip br_nf_forward_finish br_nf_post_routing <- pkt_type is updated to PACKET_HOST br_nf_dev_queue_xmit <- but not reverted to its original value vxlan_xmit vxlan_xmit_one skb_tunnel_check_pmtu <- a check on pkt_type is performed In this specific case, this creates issues such as when an ICMPv6 PTB should be sent back. When CONFIG_BRIDGE_NETFILTER is enabled, the PTB isn't sent (as skb_tunnel_check_pmtu checks if pkt_type is PACKET_HOST and returns early). If the comment is right and no one cares about the value of skb->pkt_type after br_dev_queue_push_xmit (which isn't true), resetting it to its original value should be safe. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Antoine Tenart Reviewed-by: Florian Westphal Link: https://lore.kernel.org/r/20201123174902.622102-1-atenart@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dadddde259a19105ee69e788835f4d4552767aa9 Author: Eyal Birger Date: Sat Nov 21 08:28:17 2020 +0200 net/packet: fix packet receive on L3 devices without visible hard header [ Upstream commit d549699048b4b5c22dd710455bcdb76966e55aa3 ] In the patchset merged by commit b9fcf0a0d826 ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which did not have header_ops were given one for the purpose of protocol parsing on af_packet transmit path. That change made af_packet receive path regard these devices as having a visible L3 header and therefore aligned incoming skb->data to point to the skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not reset their mac_header prior to ingress and therefore their incoming packets became malformed. Ideally these devices would reset their mac headers, or af_packet would be able to rely on dev->hard_header_len being 0 for such cases, but it seems this is not the case. Fix by changing af_packet RX ll visibility criteria to include the existence of a '.create()' header operation, which is used when creating a device hard header - via dev_hard_header() - by upper layers, and does not exist in these L3 devices. As this predicate may be useful in other situations, add it as a common dev_has_header() helper in netdevice.h. Fixes: b9fcf0a0d826 ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") Signed-off-by: Eyal Birger Acked-by: Jason A. Donenfeld Acked-by: Willem de Bruijn Link: https://lore.kernel.org/r/20201121062817.3178900-1-eyal.birger@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8c886dc8028f21ff86f3ef311b72bd2b816dbad0 Author: Paolo Abeni Date: Thu Nov 26 15:17:53 2020 +0100 mptcp: fix NULL ptr dereference on bad MPJ [ Upstream commit d3ab78858f1451351221061a1c365495df196500 ] If an msk listener receives an MPJ carrying an invalid token, it will zero the request socket msk entry. That should later cause fallback and subflow reset - as per RFC - at subflow_syn_recv_sock() time due to failing hmac validation. Since commit 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()"), we unconditionally dereference - in mptcp_can_accept_new_subflow - the subflow request msk before performing hmac validation. In the above scenario we hit a NULL ptr dereference. Address the issue doing the hmac validation earlier. Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()") Tested-by: Davide Caratti Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Link: https://lore.kernel.org/r/03b2cfa3ac80d8fc18272edc6442a9ddf0b1e34e.1606400227.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2e7dd95046203bd05e8f4dc06ee53cace70a8e3c Author: Stefano Garzarella Date: Fri Nov 20 11:47:36 2020 +0100 vsock/virtio: discard packets only when socket is really closed [ Upstream commit 3fe356d58efae54dade9ec94ea7c919ed20cf4db ] Starting from commit 8692cefc433f ("virtio_vsock: Fix race condition in virtio_transport_recv_pkt"), we discard packets in virtio_transport_recv_pkt() if the socket has been released. When the socket is connected, we schedule a delayed work to wait the RST packet from the other peer, also if SHUTDOWN_MASK is set in sk->sk_shutdown. This is done to complete the virtio-vsock shutdown algorithm, releasing the port assigned to the socket definitively only when the other peer has consumed all the packets. If we discard the RST packet received, the socket will be closed only when the VSOCK_CLOSE_TIMEOUT is reached. Sergio discovered the issue while running ab(1) HTTP benchmark using libkrun [1] and observing a latency increase with that commit. To avoid this issue, we discard packet only if the socket is really closed (SOCK_DONE flag is set). We also set SOCK_DONE in virtio_transport_release() when we don't need to wait any packets from the other peer (we didn't schedule the delayed work). In this case we remove the socket from the vsock lists, releasing the port assigned. [1] https://github.com/containers/libkrun Fixes: 8692cefc433f ("virtio_vsock: Fix race condition in virtio_transport_recv_pkt") Cc: justin.he@arm.com Reported-by: Sergio Lopez Tested-by: Sergio Lopez Signed-off-by: Stefano Garzarella Acked-by: Jia He Link: https://lore.kernel.org/r/20201120104736.73749-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 640b4434fb903e882a3bfb1f35d60981b3fa7ae9 Author: Yves-Alexis Perez Date: Thu Nov 19 18:24:39 2020 +0100 usbnet: ipheth: fix connectivity with iOS 14 [ Upstream commit f33d9e2b48a34e1558b67a473a1fc1d6e793f93c ] Starting with iOS 14 released in September 2020, connectivity using the personal hotspot USB tethering function of iOS devices is broken. Communication between the host and the device (for example ICMP traffic or DNS resolution using the DNS service running in the device itself) works fine, but communication to endpoints further away doesn't work. Investigation on the matter shows that no UDP and ICMP traffic from the tethered host is reaching the Internet at all. For TCP traffic there are exchanges between tethered host and server but packets are modified in transit leading to impossible communication. After some trials Matti Vuorela discovered that reducing the URB buffer size by two bytes restored the previous behavior. While a better solution might exist to fix the issue, since the protocol is not publicly documented and considering the small size of the fix, let's do that. Tested-by: Matti Vuorela Signed-off-by: Yves-Alexis Perez Link: https://lore.kernel.org/linux-usb/CAAn0qaXmysJ9vx3ZEMkViv_B19ju-_ExN8Yn_uSefxpjS6g4Lw@mail.gmail.com/ Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038 Link: https://lore.kernel.org/r/20201119172439.94988-1-corsac@corsac.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6d568992ab78f4b819984c188e21f76de784081a Author: Jens Axboe Date: Fri Nov 20 07:59:54 2020 -0700 tun: honor IOCB_NOWAIT flag [ Upstream commit 5aac0390a63b8718237a61dd0d24a29201d1c94a ] tun only checks the file O_NONBLOCK flag, but it should also be checking the iocb IOCB_NOWAIT flag. Any fops using ->read/write_iter() should check both, otherwise it breaks users that correctly expect O_NONBLOCK semantics if IOCB_NOWAIT is set. Signed-off-by: Jens Axboe Link: https://lore.kernel.org/r/e9451860-96cc-c7c7-47b8-fe42cadd5f4c@kernel.dk Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bd2585b7c821bfc81f7badbf04634d6cb988c722 Author: Alexander Duyck Date: Thu Nov 19 13:23:58 2020 -0800 tcp: Set INET_ECN_xmit configuration in tcp_reinit_congestion_control [ Upstream commit 55472017a4219ca965a957584affdb17549ae4a4 ] When setting congestion control via a BPF program it is seen that the SYN/ACK for packets within a given flow will not include the ECT0 flag. A bit of simple printk debugging shows that when this is configured without BPF we will see the value INET_ECN_xmit value initialized in tcp_assign_congestion_control however when we configure this via BPF the socket is in the closed state and as such it isn't configured, and I do not see it being initialized when we transition the socket into the listen state. The result of this is that the ECT0 bit is configured based on whatever the default state is for the socket. Any easy way to reproduce this is to monitor the following with tcpdump: tools/testing/selftests/bpf/test_progs -t bpf_tcp_ca Without this patch the SYN/ACK will follow whatever the default is. If dctcp all SYN/ACK packets will have the ECT0 bit set, and if it is not then ECT0 will be cleared on all SYN/ACK packets. With this patch applied the SYN/ACK bit matches the value seen on the other packets in the given stream. Fixes: 91b5b21c7c16 ("bpf: Add support for changing congestion control") Signed-off-by: Alexander Duyck Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3f7cf0545e037e62ca5522005fc860bfe994b3f0 Author: Willem de Bruijn Date: Thu Nov 26 10:12:20 2020 -0500 sock: set sk_err to ee_errno on dequeue from errq [ Upstream commit 985f7337421a811cb354ca93882f943c8335a6f5 ] When setting sk_err, set it to ee_errno, not ee_origin. Commit f5f99309fa74 ("sock: do not set sk_err in sock_dequeue_err_skb") disabled updating sk_err on errq dequeue, which is correct for most error types (origins): - sk->sk_err = err; Commit 38b257938ac6 ("sock: reset sk_err when the error queue is empty") reenabled the behavior for IMCP origins, which do require it: + if (icmp_next) + sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_origin; But read from ee_errno. Fixes: 38b257938ac6 ("sock: reset sk_err when the error queue is empty") Reported-by: Ayush Ranjan Signed-off-by: Willem de Bruijn Acked-by: Soheil Hassas Yeganeh Link: https://lore.kernel.org/r/20201126151220.2819322-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d9aec3148d1e34135cc7920ad50e7dd93f07aef1 Author: Anmol Karn Date: Fri Nov 20 00:40:43 2020 +0530 rose: Fix Null pointer dereference in rose_send_frame() [ Upstream commit 3b3fd068c56e3fbea30090859216a368398e39bf ] rose_send_frame() dereferences `neigh->dev` when called from rose_transmit_clear_request(), and the first occurrence of the `neigh` is in rose_loopback_timer() as `rose_loopback_neigh`, and it is initialized in rose_add_loopback_neigh() as NULL. i.e when `rose_loopback_neigh` used in rose_loopback_timer() its `->dev` was still NULL and rose_loopback_timer() was calling rose_rx_call_request() without checking for NULL. - net/rose/rose_link.c This bug seems to get triggered in this line: rose_call = (ax25_address *)neigh->dev->dev_addr; Fix it by adding NULL checking for `rose_loopback_neigh->dev` in rose_loopback_timer(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Jakub Kicinski Reported-by: syzbot+a1c743815982d9496393@syzkaller.appspotmail.com Tested-by: syzbot+a1c743815982d9496393@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3 Signed-off-by: Anmol Karn Link: https://lore.kernel.org/r/20201119191043.28813-1-anmol.karan123@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e2d5b96090490649ad508917c25c91e1011c8356 Author: Maxim Mikityanskiy Date: Wed Nov 25 14:18:10 2020 -0800 net/tls: Protect from calling tls_dev_del for TLS RX twice [ Upstream commit 025cc2fb6a4e84e9a0552c0017dcd1c24b7ac7da ] tls_device_offload_cleanup_rx doesn't clear tls_ctx->netdev after calling tls_dev_del if TLX TX offload is also enabled. Clearing tls_ctx->netdev gets postponed until tls_device_gc_task. It leaves a time frame when tls_device_down may get called and call tls_dev_del for RX one extra time, confusing the driver, which may lead to a crash. This patch corrects this racy behavior by adding a flag to prevent tls_device_down from calling tls_dev_del the second time. Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Saeed Mahameed Link: https://lore.kernel.org/r/20201125221810.69870-1-saeedm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 176ee7dd1b83e7bbb4564aaba4192f051e8ee843 Author: Vadim Fedorenko Date: Thu Nov 19 18:59:48 2020 +0300 net/tls: missing received data after fast remote close [ Upstream commit 20ffc7adf53a5fd3d19751fbff7895bcca66686e ] In case when tcp socket received FIN after some data and the parser haven't started before reading data caller will receive an empty buffer. This behavior differs from plain TCP socket and leads to special treating in user-space. The flow that triggers the race is simple. Server sends small amount of data right after the connection is configured to use TLS and closes the connection. In this case receiver sees TLS Handshake data, configures TLS socket right after Change Cipher Spec record. While the configuration is in process, TCP socket receives small Application Data record, Encrypted Alert record and FIN packet. So the TCP socket changes sk_shutdown to RCV_SHUTDOWN and sk_flag with SK_DONE bit set. The received data is not parsed upon arrival and is never sent to user-space. Patch unpauses parser directly if we have unparsed data in tcp receive queue. Fixes: fcf4793e278e ("tls: check RCV_SHUTDOWN in tls_wait_data") Signed-off-by: Vadim Fedorenko Link: https://lore.kernel.org/r/1605801588-12236-1-git-send-email-vfedorenko@novek.ru Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ff764c1b5150b1e71f9a3deadc7a69b8e6805eb1 Author: Eelco Chaudron Date: Tue Nov 24 07:34:44 2020 -0500 net: openvswitch: fix TTL decrement action netlink message format [ Upstream commit 69929d4c49e182f8526d42c43b37b460d562d3a0 ] Currently, the openvswitch module is not accepting the correctly formated netlink message for the TTL decrement action. For both setting and getting the dec_ttl action, the actions should be nested in the OVS_DEC_TTL_ATTR_ACTION attribute as mentioned in the openvswitch.h uapi. When the original patch was sent, it was tested with a private OVS userspace implementation. This implementation was unfortunately not upstreamed and reviewed, hence an erroneous version of this patch was sent out. Leaving the patch as-is would cause problems as the kernel module could interpret additional attributes as actions and vice-versa, due to the actions not being encapsulated/nested within the actual attribute, but being concatinated after it. Fixes: 744676e77720 ("openvswitch: add TTL decrement action") Signed-off-by: Eelco Chaudron Link: https://lore.kernel.org/r/160622121495.27296.888010441924340582.stgit@wsfd-netdev64.ntdv.lab.eng.bos.redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ca18ad48e149171efbcc669420f809f703ca8a43 Author: Julian Wiedmann Date: Fri Nov 20 11:06:57 2020 +0100 net/af_iucv: set correct sk_protocol for child sockets [ Upstream commit c5dab0941fcdc9664eb0ec0d4d51433216d91336 ] Child sockets erroneously inherit their parent's sk_type (ie. SOCK_*), instead of the PF_IUCV protocol that the parent was created with in iucv_sock_create(). We're currently not using sk->sk_protocol ourselves, so this shouldn't have much impact (except eg. getting the output in skb_dump() right). Fixes: eac3731bd04c ("[S390]: Add AF_IUCV socket support") Signed-off-by: Julian Wiedmann Link: https://lore.kernel.org/r/20201120100657.34407-1-jwi@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5f15dc79607813fe4dcd6e605b0bf2e5b7c9b03d Author: Wang Hai Date: Tue Nov 24 15:17:28 2020 +0800 ipv6: addrlabel: fix possible memory leak in ip6addrlbl_net_init [ Upstream commit e255e11e66da8281e337e4e352956e8a4999fca4 ] kmemleak report a memory leak as follows: unreferenced object 0xffff8880059c6a00 (size 64): comm "ip", pid 23696, jiffies 4296590183 (age 1755.384s) hex dump (first 32 bytes): 20 01 00 10 00 00 00 00 00 00 00 00 00 00 00 00 ............... 1c 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 ................ backtrace: [<00000000aa4e7a87>] ip6addrlbl_add+0x90/0xbb0 [<0000000070b8d7f1>] ip6addrlbl_net_init+0x109/0x170 [<000000006a9ca9d4>] ops_init+0xa8/0x3c0 [<000000002da57bf2>] setup_net+0x2de/0x7e0 [<000000004e52d573>] copy_net_ns+0x27d/0x530 [<00000000b07ae2b4>] create_new_namespaces+0x382/0xa30 [<000000003b76d36f>] unshare_nsproxy_namespaces+0xa1/0x1d0 [<0000000030653721>] ksys_unshare+0x3a4/0x780 [<0000000007e82e40>] __x64_sys_unshare+0x2d/0x40 [<0000000031a10c08>] do_syscall_64+0x33/0x40 [<0000000099df30e7>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 We should free all rules when we catch an error in ip6addrlbl_net_init(). otherwise a memory leak will occur. Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.") Reported-by: Hulk Robot Signed-off-by: Wang Hai Link: https://lore.kernel.org/r/20201124071728.8385-1-wanghai38@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d2d2a882000c6de3a106a0932a33b2b56d405b6c Author: Parav Pandit Date: Wed Nov 25 11:16:20 2020 +0200 devlink: Make sure devlink instance and port are in same net namespace [ Upstream commit a7b43649507dae4e55ff0087cad4e4dd1c6d5b99 ] When devlink reload operation is not used, netdev of an Ethernet port may be present in different net namespace than the net namespace of the devlink instance. Ensure that both the devlink instance and devlink port netdev are located in same net namespace. Fixes: 070c63f20f6c ("net: devlink: allow to change namespaces during reload") Signed-off-by: Parav Pandit Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9670490edfc442d0287726a28ec7dd5f2cab0969 Author: Parav Pandit Date: Wed Nov 25 11:16:19 2020 +0200 devlink: Hold rtnl lock while reading netdev attributes [ Upstream commit b187c9b4178b87954dbc94e78a7094715794714f ] A netdevice of a devlink port can be moved to different net namespace than its parent devlink instance. This scenario occurs when devlink reload is not used. When netdevice is undergoing migration to net namespace, its ifindex and name may change. In such use case, devlink port query may read stale netdev attributes. Fix it by reading them under rtnl lock. Fixes: bfcd3a466172 ("Introduce devlink infrastructure") Signed-off-by: Parav Pandit Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman