From: Sasha Levin Date: Sun, 9 Apr 2023 12:31:05 +0000 (-0400) Subject: Fixes for 5.10 X-Git-Tag: v5.15.107~55 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a855d5b00a73292fcc3011244a0af8700f9d0b8e;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.10 Signed-off-by: Sasha Levin --- diff --git a/queue-5.10/drivers-vmbus-check-for-channel-allocation-before-lo.patch b/queue-5.10/drivers-vmbus-check-for-channel-allocation-before-lo.patch new file mode 100644 index 00000000000..d7e7480e3c1 --- /dev/null +++ b/queue-5.10/drivers-vmbus-check-for-channel-allocation-before-lo.patch @@ -0,0 +1,48 @@ +From fd7737610af0cfef28982a93763e8055100b7a4c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 17 Feb 2023 22:44:11 +0200 +Subject: Drivers: vmbus: Check for channel allocation before looking up relids + +From: Mohammed Gamal + +[ Upstream commit 1eb65c8687316c65140b48fad27133d583178e15 ] + +relid2channel() assumes vmbus channel array to be allocated when called. +However, in cases such as kdump/kexec, not all relids will be reset by the host. +When the second kernel boots and if the guest receives a vmbus interrupt during +vmbus driver initialization before vmbus_connect() is called, before it finishes, +or if it fails, the vmbus interrupt service routine is called which in turn calls +relid2channel() and can cause a null pointer dereference. + +Print a warning and error out in relid2channel() for a channel id that's invalid +in the second kernel. + +Fixes: 8b6a877c060e ("Drivers: hv: vmbus: Replace the per-CPU channel lists with a global array of channels") + +Signed-off-by: Mohammed Gamal +Reviewed-by: Dexuan Cui +Link: https://lore.kernel.org/r/20230217204411.212709-1-mgamal@redhat.com +Signed-off-by: Wei Liu +Signed-off-by: Sasha Levin +--- + drivers/hv/connection.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c +index bfd7f00a59ecf..683fdfa3e723e 100644 +--- a/drivers/hv/connection.c ++++ b/drivers/hv/connection.c +@@ -305,6 +305,10 @@ void vmbus_disconnect(void) + */ + struct vmbus_channel *relid2channel(u32 relid) + { ++ if (vmbus_connection.channels == NULL) { ++ pr_warn_once("relid2channel: relid=%d: No channels mapped!\n", relid); ++ return NULL; ++ } + if (WARN_ON(relid >= MAX_CHANNEL_RELIDS)) + return NULL; + return READ_ONCE(vmbus_connection.channels[relid]); +-- +2.39.2 + diff --git a/queue-5.10/gpio-davinci-add-irq-chip-flag-to-skip-set-wake.patch b/queue-5.10/gpio-davinci-add-irq-chip-flag-to-skip-set-wake.patch new file mode 100644 index 00000000000..f2c6683d37f --- /dev/null +++ b/queue-5.10/gpio-davinci-add-irq-chip-flag-to-skip-set-wake.patch @@ -0,0 +1,37 @@ +From e9157bf56a2fc557ea06db6b2bbaa0209be8f734 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 3 Apr 2023 12:54:43 +0530 +Subject: gpio: davinci: Add irq chip flag to skip set wake + +From: Dhruva Gole + +[ Upstream commit 7b75c4703609a3ebaf67271813521bc0281e1ec1 ] + +Add the IRQCHIP_SKIP_SET_WAKE flag since there are no special IRQ Wake +bits that can be set to enable wakeup IRQ. + +Fixes: 3d9edf09d452 ("[ARM] 4457/2: davinci: GPIO support") +Signed-off-by: Dhruva Gole +Reviewed-by: Linus Walleij +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Sasha Levin +--- + drivers/gpio/gpio-davinci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c +index 6f2138503726a..80597e90de9c6 100644 +--- a/drivers/gpio/gpio-davinci.c ++++ b/drivers/gpio/gpio-davinci.c +@@ -326,7 +326,7 @@ static struct irq_chip gpio_irqchip = { + .irq_enable = gpio_irq_enable, + .irq_disable = gpio_irq_disable, + .irq_set_type = gpio_irq_type, +- .flags = IRQCHIP_SET_TYPE_MASKED, ++ .flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_SKIP_SET_WAKE, + }; + + static void gpio_irq_handler(struct irq_desc *desc) +-- +2.39.2 + diff --git a/queue-5.10/gpio-gpio_regmap-select-regmap-instead-of-depending-.patch b/queue-5.10/gpio-gpio_regmap-select-regmap-instead-of-depending-.patch new file mode 100644 index 00000000000..567cad91a92 --- /dev/null +++ b/queue-5.10/gpio-gpio_regmap-select-regmap-instead-of-depending-.patch @@ -0,0 +1,47 @@ +From c790d539de557dda2ec27556fb160f6c4f6920e8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 25 Feb 2023 21:39:48 -0800 +Subject: gpio: GPIO_REGMAP: select REGMAP instead of depending on it + +From: Randy Dunlap + +[ Upstream commit d49765b5f4320a402fbc4ed5edfd73d87640f27c ] + +REGMAP is a hidden (not user visible) symbol. Users cannot set it +directly thru "make *config", so drivers should select it instead of +depending on it if they need it. + +Consistently using "select" or "depends on" can also help reduce +Kconfig circular dependency issues. + +Therefore, change the use of "depends on REGMAP" to "select REGMAP". + +Fixes: ebe363197e52 ("gpio: add a reusable generic gpio_chip using regmap") +Signed-off-by: Randy Dunlap +Cc: Michael Walle +Cc: Linus Walleij +Cc: Bartosz Golaszewski +Cc: linux-gpio@vger.kernel.org +Acked-by: Michael Walle +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Sasha Levin +--- + drivers/gpio/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig +index d1300fc003ed7..39f3e13664099 100644 +--- a/drivers/gpio/Kconfig ++++ b/drivers/gpio/Kconfig +@@ -99,7 +99,7 @@ config GPIO_GENERIC + tristate + + config GPIO_REGMAP +- depends on REGMAP ++ select REGMAP + tristate + + # put drivers in the right section, in alphabetical order +-- +2.39.2 + diff --git a/queue-5.10/icmp-guard-against-too-small-mtu.patch b/queue-5.10/icmp-guard-against-too-small-mtu.patch new file mode 100644 index 00000000000..88094e3699b --- /dev/null +++ b/queue-5.10/icmp-guard-against-too-small-mtu.patch @@ -0,0 +1,86 @@ +From 7aa5d36c26d1f74925db95a962c70794eb3ab52e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 30 Mar 2023 17:45:02 +0000 +Subject: icmp: guard against too small mtu + +From: Eric Dumazet + +[ Upstream commit 7d63b67125382ff0ffdfca434acbc94a38bd092b ] + +syzbot was able to trigger a panic [1] in icmp_glue_bits(), or +more exactly in skb_copy_and_csum_bits() + +There is no repro yet, but I think the issue is that syzbot +manages to lower device mtu to a small value, fooling __icmp_send() + +__icmp_send() must make sure there is enough room for the +packet to include at least the headers. + +We might in the future refactor skb_copy_and_csum_bits() and its +callers to no longer crash when something bad happens. + +[1] +kernel BUG at net/core/skbuff.c:3343 ! +invalid opcode: 0000 [#1] PREEMPT SMP KASAN +CPU: 0 PID: 15766 Comm: syz-executor.0 Not tainted 6.3.0-rc4-syzkaller-00039-gffe78bbd5121 #0 +Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 +RIP: 0010:skb_copy_and_csum_bits+0x798/0x860 net/core/skbuff.c:3343 +Code: f0 c1 c8 08 41 89 c6 e9 73 ff ff ff e8 61 48 d4 f9 e9 41 fd ff ff 48 8b 7c 24 48 e8 52 48 d4 f9 e9 c3 fc ff ff e8 c8 27 84 f9 <0f> 0b 48 89 44 24 28 e8 3c 48 d4 f9 48 8b 44 24 28 e9 9d fb ff ff +RSP: 0018:ffffc90000007620 EFLAGS: 00010246 +RAX: 0000000000000000 RBX: 00000000000001e8 RCX: 0000000000000100 +RDX: ffff8880276f6280 RSI: ffffffff87fdd138 RDI: 0000000000000005 +RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 +R10: 00000000000001e8 R11: 0000000000000001 R12: 000000000000003c +R13: 0000000000000000 R14: ffff888028244868 R15: 0000000000000b0e +FS: 00007fbc81f1c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 0000001b2df43000 CR3: 00000000744db000 CR4: 0000000000150ef0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + +icmp_glue_bits+0x7b/0x210 net/ipv4/icmp.c:353 +__ip_append_data+0x1d1b/0x39f0 net/ipv4/ip_output.c:1161 +ip_append_data net/ipv4/ip_output.c:1343 [inline] +ip_append_data+0x115/0x1a0 net/ipv4/ip_output.c:1322 +icmp_push_reply+0xa8/0x440 net/ipv4/icmp.c:370 +__icmp_send+0xb80/0x1430 net/ipv4/icmp.c:765 +ipv4_send_dest_unreach net/ipv4/route.c:1239 [inline] +ipv4_link_failure+0x5a9/0x9e0 net/ipv4/route.c:1246 +dst_link_failure include/net/dst.h:423 [inline] +arp_error_report+0xcb/0x1c0 net/ipv4/arp.c:296 +neigh_invalidate+0x20d/0x560 net/core/neighbour.c:1079 +neigh_timer_handler+0xc77/0xff0 net/core/neighbour.c:1166 +call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700 +expire_timers+0x29b/0x4b0 kernel/time/timer.c:1751 +__run_timers kernel/time/timer.c:2022 [inline] + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Reported-by: syzbot+d373d60fddbdc915e666@syzkaller.appspotmail.com +Signed-off-by: Eric Dumazet +Link: https://lore.kernel.org/r/20230330174502.1915328-1-edumazet@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ipv4/icmp.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c +index a1aacf5e75a6a..0bbc047e8f6e1 100644 +--- a/net/ipv4/icmp.c ++++ b/net/ipv4/icmp.c +@@ -755,6 +755,11 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info, + room = 576; + room -= sizeof(struct iphdr) + icmp_param.replyopts.opt.opt.optlen; + room -= sizeof(struct icmphdr); ++ /* Guard against tiny mtu. We need to include at least one ++ * IP network header for this message to make any sense. ++ */ ++ if (room <= (int)sizeof(struct iphdr)) ++ goto ende; + + icmp_param.data_len = skb_in->len - icmp_param.offset; + if (icmp_param.data_len > room) +-- +2.39.2 + diff --git a/queue-5.10/ipv6-fix-an-uninit-variable-access-bug-in-__ip6_make.patch b/queue-5.10/ipv6-fix-an-uninit-variable-access-bug-in-__ip6_make.patch new file mode 100644 index 00000000000..8bcd4312d5c --- /dev/null +++ b/queue-5.10/ipv6-fix-an-uninit-variable-access-bug-in-__ip6_make.patch @@ -0,0 +1,101 @@ +From 3b4b107b9ffc4d9598e93153e79ee12b1f4e0deb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 3 Apr 2023 15:34:17 +0800 +Subject: ipv6: Fix an uninit variable access bug in __ip6_make_skb() + +From: Ziyang Xuan + +[ Upstream commit ea30388baebcce37fd594d425a65037ca35e59e8 ] + +Syzbot reported a bug as following: + +===================================================== +BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] +BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] +BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] +BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 + arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] + arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] + atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] + __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 + ip6_finish_skb include/net/ipv6.h:1122 [inline] + ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 + rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 + rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 + inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 + sock_sendmsg_nosec net/socket.c:714 [inline] + sock_sendmsg net/socket.c:734 [inline] + ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 + ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 + __sys_sendmsg net/socket.c:2559 [inline] + __do_sys_sendmsg net/socket.c:2568 [inline] + __se_sys_sendmsg net/socket.c:2566 [inline] + __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 + do_syscall_x64 arch/x86/entry/common.c:50 [inline] + do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + +Uninit was created at: + slab_post_alloc_hook mm/slab.h:766 [inline] + slab_alloc_node mm/slub.c:3452 [inline] + __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 + __do_kmalloc_node mm/slab_common.c:967 [inline] + __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 + kmalloc_reserve net/core/skbuff.c:492 [inline] + __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 + alloc_skb include/linux/skbuff.h:1270 [inline] + __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 + ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 + rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 + inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 + sock_sendmsg_nosec net/socket.c:714 [inline] + sock_sendmsg net/socket.c:734 [inline] + ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 + ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 + __sys_sendmsg net/socket.c:2559 [inline] + __do_sys_sendmsg net/socket.c:2568 [inline] + __se_sys_sendmsg net/socket.c:2566 [inline] + __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 + do_syscall_x64 arch/x86/entry/common.c:50 [inline] + do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + +It is because icmp6hdr does not in skb linear region under the scenario +of SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly will +trigger the uninit variable access bug. + +Use a local variable icmp6_type to carry the correct value in different +scenarios. + +Fixes: 14878f75abd5 ("[IPV6]: Add ICMPMsgStats MIB (RFC 4293) [rev 2]") +Reported-by: syzbot+8257f4dcef79de670baf@syzkaller.appspotmail.com +Link: https://syzkaller.appspot.com/bug?id=3d605ec1d0a7f2a269a1a6936ac7f2b85975ee9c +Signed-off-by: Ziyang Xuan +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/ipv6/ip6_output.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c +index e427f5040a08e..c62e44224bf84 100644 +--- a/net/ipv6/ip6_output.c ++++ b/net/ipv6/ip6_output.c +@@ -1925,8 +1925,13 @@ struct sk_buff *__ip6_make_skb(struct sock *sk, + IP6_UPD_PO_STATS(net, rt->rt6i_idev, IPSTATS_MIB_OUT, skb->len); + if (proto == IPPROTO_ICMPV6) { + struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb)); ++ u8 icmp6_type; + +- ICMP6MSGOUT_INC_STATS(net, idev, icmp6_hdr(skb)->icmp6_type); ++ if (sk->sk_socket->type == SOCK_RAW && !inet_sk(sk)->hdrincl) ++ icmp6_type = fl6->fl6_icmp_type; ++ else ++ icmp6_type = icmp6_hdr(skb)->icmp6_type; ++ ICMP6MSGOUT_INC_STATS(net, idev, icmp6_type); + ICMP6_INC_STATS(net, idev, ICMP6_MIB_OUTMSGS); + } + +-- +2.39.2 + diff --git a/queue-5.10/kvm-s390-pv-fix-external-interruption-loop-not-alway.patch b/queue-5.10/kvm-s390-pv-fix-external-interruption-loop-not-alway.patch new file mode 100644 index 00000000000..48a7e6bcf56 --- /dev/null +++ b/queue-5.10/kvm-s390-pv-fix-external-interruption-loop-not-alway.patch @@ -0,0 +1,100 @@ +From bdacc99e0a8069bbb1038b00d732183b34771205 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Feb 2023 09:55:20 +0100 +Subject: KVM: s390: pv: fix external interruption loop not always detected + +From: Nico Boehr + +[ Upstream commit 21f27df854008b86349a203bf97fef79bb11f53e ] + +To determine whether the guest has caused an external interruption loop +upon code 20 (external interrupt) intercepts, the ext_new_psw needs to +be inspected to see whether external interrupts are enabled. + +Under non-PV, ext_new_psw can simply be taken from guest lowcore. Under +PV, KVM can only access the encrypted guest lowcore and hence the +ext_new_psw must not be taken from guest lowcore. + +handle_external_interrupt() incorrectly did that and hence was not able +to reliably tell whether an external interruption loop is happening or +not. False negatives cause spurious failures of my kvm-unit-test +for extint loops[1] under PV. + +Since code 20 is only caused under PV if and only if the guest's +ext_new_psw is enabled for external interrupts, false positive detection +of a external interruption loop can not happen. + +Fix this issue by instead looking at the guest PSW in the state +description. Since the PSW swap for external interrupt is done by the +ultravisor before the intercept is caused, this reliably tells whether +the guest is enabled for external interrupts in the ext_new_psw. + +Also update the comments to explain better what is happening. + +[1] https://lore.kernel.org/kvm/20220812062151.1980937-4-nrb@linux.ibm.com/ + +Signed-off-by: Nico Boehr +Reviewed-by: Janosch Frank +Reviewed-by: Christian Borntraeger +Fixes: 201ae986ead7 ("KVM: s390: protvirt: Implement interrupt injection") +Link: https://lore.kernel.org/r/20230213085520.100756-2-nrb@linux.ibm.com +Message-Id: <20230213085520.100756-2-nrb@linux.ibm.com> +Signed-off-by: Janosch Frank +Signed-off-by: Sasha Levin +--- + arch/s390/kvm/intercept.c | 32 ++++++++++++++++++++++++-------- + 1 file changed, 24 insertions(+), 8 deletions(-) + +diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c +index 77909d362b78f..5be68190901f9 100644 +--- a/arch/s390/kvm/intercept.c ++++ b/arch/s390/kvm/intercept.c +@@ -270,10 +270,18 @@ static int handle_prog(struct kvm_vcpu *vcpu) + /** + * handle_external_interrupt - used for external interruption interceptions + * +- * This interception only occurs if the CPUSTAT_EXT_INT bit was set, or if +- * the new PSW does not have external interrupts disabled. In the first case, +- * we've got to deliver the interrupt manually, and in the second case, we +- * drop to userspace to handle the situation there. ++ * This interception occurs if: ++ * - the CPUSTAT_EXT_INT bit was already set when the external interrupt ++ * occurred. In this case, the interrupt needs to be injected manually to ++ * preserve interrupt priority. ++ * - the external new PSW has external interrupts enabled, which will cause an ++ * interruption loop. We drop to userspace in this case. ++ * ++ * The latter case can be detected by inspecting the external mask bit in the ++ * external new psw. ++ * ++ * Under PV, only the latter case can occur, since interrupt priorities are ++ * handled in the ultravisor. + */ + static int handle_external_interrupt(struct kvm_vcpu *vcpu) + { +@@ -284,10 +292,18 @@ static int handle_external_interrupt(struct kvm_vcpu *vcpu) + + vcpu->stat.exit_external_interrupt++; + +- rc = read_guest_lc(vcpu, __LC_EXT_NEW_PSW, &newpsw, sizeof(psw_t)); +- if (rc) +- return rc; +- /* We can not handle clock comparator or timer interrupt with bad PSW */ ++ if (kvm_s390_pv_cpu_is_protected(vcpu)) { ++ newpsw = vcpu->arch.sie_block->gpsw; ++ } else { ++ rc = read_guest_lc(vcpu, __LC_EXT_NEW_PSW, &newpsw, sizeof(psw_t)); ++ if (rc) ++ return rc; ++ } ++ ++ /* ++ * Clock comparator or timer interrupt with external interrupt enabled ++ * will cause interrupt loop. Drop to userspace. ++ */ + if ((eic == EXT_IRQ_CLK_COMP || eic == EXT_IRQ_CPU_TIMER) && + (newpsw.mask & PSW_MASK_EXT)) + return -EOPNOTSUPP; +-- +2.39.2 + diff --git a/queue-5.10/net-don-t-let-netpoll-invoke-napi-if-in-xmit-context.patch b/queue-5.10/net-don-t-let-netpoll-invoke-napi-if-in-xmit-context.patch new file mode 100644 index 00000000000..8e211daf3fe --- /dev/null +++ b/queue-5.10/net-don-t-let-netpoll-invoke-napi-if-in-xmit-context.patch @@ -0,0 +1,80 @@ +From 4ef3ed383f188205e6eb5a95065bd40915aff984 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 30 Mar 2023 19:21:44 -0700 +Subject: net: don't let netpoll invoke NAPI if in xmit context + +From: Jakub Kicinski + +[ Upstream commit 275b471e3d2daf1472ae8fa70dc1b50c9e0b9e75 ] + +Commit 0db3dc73f7a3 ("[NETPOLL]: tx lock deadlock fix") narrowed +down the region under netif_tx_trylock() inside netpoll_send_skb(). +(At that point in time netif_tx_trylock() would lock all queues of +the device.) Taking the tx lock was problematic because driver's +cleanup method may take the same lock. So the change made us hold +the xmit lock only around xmit, and expected the driver to take +care of locking within ->ndo_poll_controller(). + +Unfortunately this only works if netpoll isn't itself called with +the xmit lock already held. Netpoll code is careful and uses +trylock(). The drivers, however, may be using plain lock(). +Printing while holding the xmit lock is going to result in rare +deadlocks. + +Luckily we record the xmit lock owners, so we can scan all the queues, +the same way we scan NAPI owners. If any of the xmit locks is held +by the local CPU we better not attempt any polling. + +It would be nice if we could narrow down the check to only the NAPIs +and the queue we're trying to use. I don't see a way to do that now. + +Reported-by: Roman Gushchin +Fixes: 0db3dc73f7a3 ("[NETPOLL]: tx lock deadlock fix") +Signed-off-by: Jakub Kicinski +Reviewed-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/core/netpoll.c | 19 ++++++++++++++++++- + 1 file changed, 18 insertions(+), 1 deletion(-) + +diff --git a/net/core/netpoll.c b/net/core/netpoll.c +index 960948290001e..2ad22511b9c6d 100644 +--- a/net/core/netpoll.c ++++ b/net/core/netpoll.c +@@ -137,6 +137,20 @@ static void queue_process(struct work_struct *work) + } + } + ++static int netif_local_xmit_active(struct net_device *dev) ++{ ++ int i; ++ ++ for (i = 0; i < dev->num_tx_queues; i++) { ++ struct netdev_queue *txq = netdev_get_tx_queue(dev, i); ++ ++ if (READ_ONCE(txq->xmit_lock_owner) == smp_processor_id()) ++ return 1; ++ } ++ ++ return 0; ++} ++ + static void poll_one_napi(struct napi_struct *napi) + { + int work; +@@ -183,7 +197,10 @@ void netpoll_poll_dev(struct net_device *dev) + if (!ni || down_trylock(&ni->dev_lock)) + return; + +- if (!netif_running(dev)) { ++ /* Some drivers will take the same locks in poll and xmit, ++ * we can't poll if local CPU is already in xmit. ++ */ ++ if (!netif_running(dev) || netif_local_xmit_active(dev)) { + up(&ni->dev_lock); + return; + } +-- +2.39.2 + diff --git a/queue-5.10/net-ethernet-ti-am65-cpsw-fix-mdio-cleanup-in-probe.patch b/queue-5.10/net-ethernet-ti-am65-cpsw-fix-mdio-cleanup-in-probe.patch new file mode 100644 index 00000000000..fb816c6ceb3 --- /dev/null +++ b/queue-5.10/net-ethernet-ti-am65-cpsw-fix-mdio-cleanup-in-probe.patch @@ -0,0 +1,57 @@ +From 1c07a66e39e25f9eca8ca5800db8e7438cd4ad60 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 3 Apr 2023 14:33:21 +0530 +Subject: net: ethernet: ti: am65-cpsw: Fix mdio cleanup in probe + +From: Siddharth Vadapalli + +[ Upstream commit c6b486fb33680ad5a3a6390ce693c835caaae3f7 ] + +In the am65_cpsw_nuss_probe() function's cleanup path, the call to +of_platform_device_destroy() for the common->mdio_dev device is invoked +unconditionally. It is possible that either the MDIO node is not present +in the device-tree, or the MDIO node is disabled in the device-tree. In +both these cases, the MDIO device is not created, resulting in a NULL +pointer dereference when the of_platform_device_destroy() function is +invoked on the common->mdio_dev device on the cleanup path. + +Fix this by ensuring that the common->mdio_dev device exists, before +attempting to invoke of_platform_device_destroy(). + +Fixes: a45cfcc69a25 ("net: ethernet: ti: am65-cpsw-nuss: use of_platform_device_create() for mdio") +Signed-off-by: Siddharth Vadapalli +Reviewed-by: Roger Quadros +Link: https://lore.kernel.org/r/20230403090321.835877-1-s-vadapalli@ti.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/ti/am65-cpsw-nuss.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c +index 4074310abcff4..e4af1f506b833 100644 +--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c ++++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c +@@ -2153,7 +2153,8 @@ static int am65_cpsw_nuss_probe(struct platform_device *pdev) + return 0; + + err_of_clear: +- of_platform_device_destroy(common->mdio_dev, NULL); ++ if (common->mdio_dev) ++ of_platform_device_destroy(common->mdio_dev, NULL); + err_pm_clear: + pm_runtime_put_sync(dev); + pm_runtime_disable(dev); +@@ -2179,7 +2180,8 @@ static int am65_cpsw_nuss_remove(struct platform_device *pdev) + */ + am65_cpsw_nuss_cleanup_ndev(common); + +- of_platform_device_destroy(common->mdio_dev, NULL); ++ if (common->mdio_dev) ++ of_platform_device_destroy(common->mdio_dev, NULL); + + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); +-- +2.39.2 + diff --git a/queue-5.10/net-qrtr-combine-nameservice-into-main-module.patch b/queue-5.10/net-qrtr-combine-nameservice-into-main-module.patch new file mode 100644 index 00000000000..837f78bc850 --- /dev/null +++ b/queue-5.10/net-qrtr-combine-nameservice-into-main-module.patch @@ -0,0 +1,48 @@ +From ee007f33fd3ada4673abfa5f4f74bfbaba6f8ec3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 28 Sep 2021 19:11:57 +0200 +Subject: net: qrtr: combine nameservice into main module + +From: Luca Weiss + +[ Upstream commit a365023a76f231cc2fc6e33797e66f3bcaa9f9a9 ] + +Previously with CONFIG_QRTR=m a separate ns.ko would be built which +wasn't done on purpose and should be included in qrtr.ko. + +Rename qrtr.c to af_qrtr.c so we can build a qrtr.ko with both af_qrtr.c +and ns.c. + +Signed-off-by: Luca Weiss +Reviewed-by: Bjorn Andersson +Tested-By: Steev Klimaszewski +Reviewed-by: Manivannan Sadhasivam +Link: https://lore.kernel.org/r/20210928171156.6353-1-luca@z3ntu.xyz +Signed-off-by: Jakub Kicinski +Stable-dep-of: 44d807320000 ("net: qrtr: Fix a refcount bug in qrtr_recvmsg()") +Signed-off-by: Sasha Levin +--- + net/qrtr/Makefile | 3 ++- + net/qrtr/{qrtr.c => af_qrtr.c} | 0 + 2 files changed, 2 insertions(+), 1 deletion(-) + rename net/qrtr/{qrtr.c => af_qrtr.c} (100%) + +diff --git a/net/qrtr/Makefile b/net/qrtr/Makefile +index 1b1411d158a73..8e0605f88a73d 100644 +--- a/net/qrtr/Makefile ++++ b/net/qrtr/Makefile +@@ -1,5 +1,6 @@ + # SPDX-License-Identifier: GPL-2.0-only +-obj-$(CONFIG_QRTR) := qrtr.o ns.o ++obj-$(CONFIG_QRTR) += qrtr.o ++qrtr-y := af_qrtr.o ns.o + + obj-$(CONFIG_QRTR_SMD) += qrtr-smd.o + qrtr-smd-y := smd.o +diff --git a/net/qrtr/qrtr.c b/net/qrtr/af_qrtr.c +similarity index 100% +rename from net/qrtr/qrtr.c +rename to net/qrtr/af_qrtr.c +-- +2.39.2 + diff --git a/queue-5.10/net-qrtr-do-not-do-del_server-broadcast-after-del_cl.patch b/queue-5.10/net-qrtr-do-not-do-del_server-broadcast-after-del_cl.patch new file mode 100644 index 00000000000..c3a8ee53488 --- /dev/null +++ b/queue-5.10/net-qrtr-do-not-do-del_server-broadcast-after-del_cl.patch @@ -0,0 +1,94 @@ +From c150ddbd2df5d0c3afefb41c5d05ce84d23882ba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 3 Apr 2023 12:28:51 +0530 +Subject: net: qrtr: Do not do DEL_SERVER broadcast after DEL_CLIENT + +From: Sricharan Ramabadhran + +[ Upstream commit 839349d13905927d8a567ca4d21d88c82028e31d ] + +On the remote side, when QRTR socket is removed, af_qrtr will call +qrtr_port_remove() which broadcasts the DEL_CLIENT packet to all neighbours +including local NS. NS upon receiving the DEL_CLIENT packet, will remove +the lookups associated with the node:port and broadcasts the DEL_SERVER +packet. + +But on the host side, due to the arrival of the DEL_CLIENT packet, the NS +would've already deleted the server belonging to that port. So when the +remote's NS again broadcasts the DEL_SERVER for that port, it throws below +error message on the host: + +"failed while handling packet from 2:-2" + +So fix this error by not broadcasting the DEL_SERVER packet when the +DEL_CLIENT packet gets processed." + +Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") +Reviewed-by: Manivannan Sadhasivam +Signed-off-by: Ram Kumar Dharuman +Signed-off-by: Sricharan Ramabadhran +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/qrtr/ns.c | 15 +++++++++------ + 1 file changed, 9 insertions(+), 6 deletions(-) + +diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c +index fe81e03851686..713e9940d88bb 100644 +--- a/net/qrtr/ns.c ++++ b/net/qrtr/ns.c +@@ -273,7 +273,7 @@ static struct qrtr_server *server_add(unsigned int service, + return NULL; + } + +-static int server_del(struct qrtr_node *node, unsigned int port) ++static int server_del(struct qrtr_node *node, unsigned int port, bool bcast) + { + struct qrtr_lookup *lookup; + struct qrtr_server *srv; +@@ -286,7 +286,7 @@ static int server_del(struct qrtr_node *node, unsigned int port) + radix_tree_delete(&node->servers, port); + + /* Broadcast the removal of local servers */ +- if (srv->node == qrtr_ns.local_node) ++ if (srv->node == qrtr_ns.local_node && bcast) + service_announce_del(&qrtr_ns.bcast_sq, srv); + + /* Announce the service's disappearance to observers */ +@@ -372,7 +372,7 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from) + } + slot = radix_tree_iter_resume(slot, &iter); + rcu_read_unlock(); +- server_del(node, srv->port); ++ server_del(node, srv->port, true); + rcu_read_lock(); + } + rcu_read_unlock(); +@@ -458,10 +458,13 @@ static int ctrl_cmd_del_client(struct sockaddr_qrtr *from, + kfree(lookup); + } + +- /* Remove the server belonging to this port */ ++ /* Remove the server belonging to this port but don't broadcast ++ * DEL_SERVER. Neighbours would've already removed the server belonging ++ * to this port due to the DEL_CLIENT broadcast from qrtr_port_remove(). ++ */ + node = node_get(node_id); + if (node) +- server_del(node, port); ++ server_del(node, port, false); + + /* Advertise the removal of this client to all local servers */ + local_node = node_get(qrtr_ns.local_node); +@@ -574,7 +577,7 @@ static int ctrl_cmd_del_server(struct sockaddr_qrtr *from, + if (!node) + return -ENOENT; + +- return server_del(node, port); ++ return server_del(node, port, true); + } + + static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from, +-- +2.39.2 + diff --git a/queue-5.10/net-qrtr-fix-a-refcount-bug-in-qrtr_recvmsg.patch b/queue-5.10/net-qrtr-fix-a-refcount-bug-in-qrtr_recvmsg.patch new file mode 100644 index 00000000000..dc52300bd2d --- /dev/null +++ b/queue-5.10/net-qrtr-fix-a-refcount-bug-in-qrtr_recvmsg.patch @@ -0,0 +1,77 @@ +From 3b226c36213f45fdee67db264ff40111b76fc381 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 30 Mar 2023 09:25:32 +0800 +Subject: net: qrtr: Fix a refcount bug in qrtr_recvmsg() + +From: Ziyang Xuan + +[ Upstream commit 44d807320000db0d0013372ad39b53e12d52f758 ] + +Syzbot reported a bug as following: + +refcount_t: addition on 0; use-after-free. +... +RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25 +... +Call Trace: + + __refcount_add include/linux/refcount.h:199 [inline] + __refcount_inc include/linux/refcount.h:250 [inline] + refcount_inc include/linux/refcount.h:267 [inline] + kref_get include/linux/kref.h:45 [inline] + qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline] + qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline] + qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline] + qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070 + sock_recvmsg_nosec net/socket.c:1017 [inline] + sock_recvmsg+0xe2/0x160 net/socket.c:1038 + qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688 + process_one_work+0x991/0x15c0 kernel/workqueue.c:2390 + worker_thread+0x669/0x1090 kernel/workqueue.c:2537 + +It occurs in the concurrent scenario of qrtr_recvmsg() and +qrtr_endpoint_unregister() as following: + + cpu0 cpu1 +qrtr_recvmsg qrtr_endpoint_unregister +qrtr_send_resume_tx qrtr_node_release +qrtr_node_lookup mutex_lock(&qrtr_node_lock) +spin_lock_irqsave(&qrtr_nodes_lock, ) refcount_dec_and_test(&node->ref) [node->ref == 0] +radix_tree_lookup [node != NULL] __qrtr_node_release +qrtr_node_acquire spin_lock_irqsave(&qrtr_nodes_lock, ) +kref_get(&node->ref) [WARNING] ... + mutex_unlock(&qrtr_node_lock) + +Use qrtr_node_lock to protect qrtr_node_lookup() implementation, this +is actually improving the protection of node reference. + +Fixes: 0a7e0d0ef054 ("net: qrtr: Migrate node lookup tree to spinlock") +Reported-by: syzbot+a7492efaa5d61b51db23@syzkaller.appspotmail.com +Link: https://syzkaller.appspot.com/bug?extid=a7492efaa5d61b51db23 +Signed-off-by: Ziyang Xuan +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/qrtr/af_qrtr.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/net/qrtr/af_qrtr.c b/net/qrtr/af_qrtr.c +index 13448ca5aeff2..d0f0b2b8dce2f 100644 +--- a/net/qrtr/af_qrtr.c ++++ b/net/qrtr/af_qrtr.c +@@ -388,10 +388,12 @@ static struct qrtr_node *qrtr_node_lookup(unsigned int nid) + struct qrtr_node *node; + unsigned long flags; + ++ mutex_lock(&qrtr_node_lock); + spin_lock_irqsave(&qrtr_nodes_lock, flags); + node = radix_tree_lookup(&qrtr_nodes, nid); + node = qrtr_node_acquire(node); + spin_unlock_irqrestore(&qrtr_nodes_lock, flags); ++ mutex_unlock(&qrtr_node_lock); + + return node; + } +-- +2.39.2 + diff --git a/queue-5.10/net-stmmac-fix-up-rx-flow-hash-indirection-table-whe.patch b/queue-5.10/net-stmmac-fix-up-rx-flow-hash-indirection-table-whe.patch new file mode 100644 index 00000000000..11b24e44eb4 --- /dev/null +++ b/queue-5.10/net-stmmac-fix-up-rx-flow-hash-indirection-table-whe.patch @@ -0,0 +1,86 @@ +From 376f75e2f7aa9fecbe701065d55023f7c7f99d2d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 3 Apr 2023 14:11:20 +0200 +Subject: net: stmmac: fix up RX flow hash indirection table when setting + channels + +From: Corinna Vinschen + +[ Upstream commit 218c597325f4faf7b7a6049233a30d7842b5b2dc ] + +stmmac_reinit_queues() fails to fix up the RX hash. Even if the number +of channels gets restricted, the output of `ethtool -x' indicates that +all RX queues are used: + + $ ethtool -l enp0s29f2 + Channel parameters for enp0s29f2: + Pre-set maximums: + RX: 8 + TX: 8 + Other: n/a + Combined: n/a + Current hardware settings: + RX: 8 + TX: 8 + Other: n/a + Combined: n/a + $ ethtool -x enp0s29f2 + RX flow hash indirection table for enp0s29f2 with 8 RX ring(s): + 0: 0 1 2 3 4 5 6 7 + 8: 0 1 2 3 4 5 6 7 + [...] + $ ethtool -L enp0s29f2 rx 3 + $ ethtool -x enp0s29f2 + RX flow hash indirection table for enp0s29f2 with 3 RX ring(s): + 0: 0 1 2 3 4 5 6 7 + 8: 0 1 2 3 4 5 6 7 + [...] + +Fix this by setting the indirection table according to the number +of specified queues. The result is now as expected: + + $ ethtool -L enp0s29f2 rx 3 + $ ethtool -x enp0s29f2 + RX flow hash indirection table for enp0s29f2 with 3 RX ring(s): + 0: 0 1 2 0 1 2 0 1 + 8: 2 0 1 2 0 1 2 0 + [...] + +Tested on Intel Elkhart Lake. + +Fixes: 0366f7e06a6b ("net: stmmac: add ethtool support for get/set channels") +Signed-off-by: Corinna Vinschen +Link: https://lore.kernel.org/r/20230403121120.489138-1-vinschen@redhat.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +index 04c59102a2863..de66406c50572 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c ++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +@@ -4940,7 +4940,7 @@ static void stmmac_napi_del(struct net_device *dev) + int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt) + { + struct stmmac_priv *priv = netdev_priv(dev); +- int ret = 0; ++ int ret = 0, i; + + if (netif_running(dev)) + stmmac_release(dev); +@@ -4949,6 +4949,10 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt) + + priv->plat->rx_queues_to_use = rx_cnt; + priv->plat->tx_queues_to_use = tx_cnt; ++ if (!netif_is_rxfh_configured(dev)) ++ for (i = 0; i < ARRAY_SIZE(priv->rss.table); i++) ++ priv->rss.table[i] = ethtool_rxfh_indir_default(i, ++ rx_cnt); + + stmmac_napi_add(dev); + +-- +2.39.2 + diff --git a/queue-5.10/nfsd-callback-request-does-not-use-correct-credentia.patch b/queue-5.10/nfsd-callback-request-does-not-use-correct-credentia.patch new file mode 100644 index 00000000000..126f85708ff --- /dev/null +++ b/queue-5.10/nfsd-callback-request-does-not-use-correct-credentia.patch @@ -0,0 +1,43 @@ +From c9d2e70a5755cd1ab2deb3b68724d7e062291733 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 1 Apr 2023 13:22:08 -0700 +Subject: NFSD: callback request does not use correct credential for AUTH_SYS + +From: Dai Ngo + +[ Upstream commit 7de82c2f36fb26aa78440bbf0efcf360b691d98b ] + +Currently callback request does not use the credential specified in +CREATE_SESSION if the security flavor for the back channel is AUTH_SYS. + +Problem was discovered by pynfs 4.1 DELEG5 and DELEG7 test with error: +DELEG5 st_delegation.testCBSecParms : FAILURE + expected callback with uid, gid == 17, 19, got 0, 0 + +Signed-off-by: Dai Ngo +Reviewed-by: Jeff Layton +Fixes: 8276c902bbe9 ("SUNRPC: remove uid and gid from struct auth_cred") +Signed-off-by: Chuck Lever +Signed-off-by: Sasha Levin +--- + fs/nfsd/nfs4callback.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c +index af2064e36ac61..f5b7ad0847f20 100644 +--- a/fs/nfsd/nfs4callback.c ++++ b/fs/nfsd/nfs4callback.c +@@ -875,8 +875,8 @@ static const struct cred *get_backchannel_cred(struct nfs4_client *clp, struct r + if (!kcred) + return NULL; + +- kcred->uid = ses->se_cb_sec.uid; +- kcred->gid = ses->se_cb_sec.gid; ++ kcred->fsuid = ses->se_cb_sec.uid; ++ kcred->fsgid = ses->se_cb_sec.gid; + return kcred; + } + } +-- +2.39.2 + diff --git a/queue-5.10/pwm-cros-ec-explicitly-set-.polarity-in-.get_state.patch b/queue-5.10/pwm-cros-ec-explicitly-set-.polarity-in-.get_state.patch new file mode 100644 index 00000000000..51580ef418b --- /dev/null +++ b/queue-5.10/pwm-cros-ec-explicitly-set-.polarity-in-.get_state.patch @@ -0,0 +1,40 @@ +From 9949f3e2bdb6406dcaf359c10e3af32f1f989cf2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 22 Mar 2023 22:45:41 +0100 +Subject: pwm: cros-ec: Explicitly set .polarity in .get_state() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Uwe Kleine-König + +[ Upstream commit 30006b77c7e130e01d1ab2148cc8abf73dfcc4bf ] + +The driver only supports normal polarity. Complete the implementation of +.get_state() by setting .polarity accordingly. + +Reviewed-by: Guenter Roeck +Fixes: 1f0d3bb02785 ("pwm: Add ChromeOS EC PWM driver") +Link: https://lore.kernel.org/r/20230228135508.1798428-3-u.kleine-koenig@pengutronix.de +Signed-off-by: Uwe Kleine-König +Signed-off-by: Thierry Reding +Signed-off-by: Sasha Levin +--- + drivers/pwm/pwm-cros-ec.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c +index c1c337969e4ec..d4f4a133656c7 100644 +--- a/drivers/pwm/pwm-cros-ec.c ++++ b/drivers/pwm/pwm-cros-ec.c +@@ -154,6 +154,7 @@ static void cros_ec_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, + + state->enabled = (ret > 0); + state->period = EC_PWM_MAX_DUTY; ++ state->polarity = PWM_POLARITY_NORMAL; + + /* + * Note that "disabled" and "duty cycle == 0" are treated the same. If +-- +2.39.2 + diff --git a/queue-5.10/pwm-sprd-explicitly-set-.polarity-in-.get_state.patch b/queue-5.10/pwm-sprd-explicitly-set-.polarity-in-.get_state.patch new file mode 100644 index 00000000000..d70180e9862 --- /dev/null +++ b/queue-5.10/pwm-sprd-explicitly-set-.polarity-in-.get_state.patch @@ -0,0 +1,39 @@ +From 0592888cae756ef6edda857e002dab5958e2ea45 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 22 Mar 2023 22:45:43 +0100 +Subject: pwm: sprd: Explicitly set .polarity in .get_state() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Uwe Kleine-König + +[ Upstream commit 2be4dcf6627e1bcbbef8e6ba1811f5127d39202c ] + +The driver only supports normal polarity. Complete the implementation of +.get_state() by setting .polarity accordingly. + +Fixes: 8aae4b02e8a6 ("pwm: sprd: Add Spreadtrum PWM support") +Link: https://lore.kernel.org/r/20230228135508.1798428-5-u.kleine-koenig@pengutronix.de +Signed-off-by: Uwe Kleine-König +Signed-off-by: Thierry Reding +Signed-off-by: Sasha Levin +--- + drivers/pwm/pwm-sprd.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/pwm/pwm-sprd.c b/drivers/pwm/pwm-sprd.c +index 9eeb59cb81b68..b23456d38bd22 100644 +--- a/drivers/pwm/pwm-sprd.c ++++ b/drivers/pwm/pwm-sprd.c +@@ -109,6 +109,7 @@ static void sprd_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, + duty = val & SPRD_PWM_DUTY_MSK; + tmp = (prescale + 1) * NSEC_PER_SEC * duty; + state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, chn->clk_rate); ++ state->polarity = PWM_POLARITY_NORMAL; + + /* Disable PWM clocks if the PWM channel is not in enable state. */ + if (!state->enabled) +-- +2.39.2 + diff --git a/queue-5.10/sctp-check-send-stream-number-after-wait_for_sndbuf.patch b/queue-5.10/sctp-check-send-stream-number-after-wait_for_sndbuf.patch new file mode 100644 index 00000000000..d61045bbd68 --- /dev/null +++ b/queue-5.10/sctp-check-send-stream-number-after-wait_for_sndbuf.patch @@ -0,0 +1,66 @@ +From 54b43b51aedbe707a459054606d33d5daa288f78 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 1 Apr 2023 19:09:57 -0400 +Subject: sctp: check send stream number after wait_for_sndbuf + +From: Xin Long + +[ Upstream commit 2584024b23552c00d95b50255e47bd18d306d31a ] + +This patch fixes a corner case where the asoc out stream count may change +after wait_for_sndbuf. + +When the main thread in the client starts a connection, if its out stream +count is set to N while the in stream count in the server is set to N - 2, +another thread in the client keeps sending the msgs with stream number +N - 1, and waits for sndbuf before processing INIT_ACK. + +However, after processing INIT_ACK, the out stream count in the client is +shrunk to N - 2, the same to the in stream count in the server. The crash +occurs when the thread waiting for sndbuf is awake and sends the msg in a +non-existing stream(N - 1), the call trace is as below: + + KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] + Call Trace: + + sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline] + sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline] + sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] + sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 + sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 + sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 + sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 + inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 + sock_sendmsg_nosec net/socket.c:722 [inline] + sock_sendmsg+0xde/0x190 net/socket.c:745 + +The fix is to add an unlikely check for the send stream number after the +thread wakes up from the wait_for_sndbuf. + +Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") +Reported-by: syzbot+47c24ca20a2fa01f082e@syzkaller.appspotmail.com +Signed-off-by: Xin Long +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/sctp/socket.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/net/sctp/socket.c b/net/sctp/socket.c +index e9b4ea3d934fa..3a68d65f7d153 100644 +--- a/net/sctp/socket.c ++++ b/net/sctp/socket.c +@@ -1831,6 +1831,10 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, + err = sctp_wait_for_sndbuf(asoc, &timeo, msg_len); + if (err) + goto err; ++ if (unlikely(sinfo->sinfo_stream >= asoc->stream.outcnt)) { ++ err = -EINVAL; ++ goto err; ++ } + } + + if (sctp_state(asoc, CLOSED)) { +-- +2.39.2 + diff --git a/queue-5.10/series b/queue-5.10/series new file mode 100644 index 00000000000..6a90cdba59f --- /dev/null +++ b/queue-5.10/series @@ -0,0 +1,18 @@ +gpio-gpio_regmap-select-regmap-instead-of-depending-.patch +drivers-vmbus-check-for-channel-allocation-before-lo.patch +pwm-cros-ec-explicitly-set-.polarity-in-.get_state.patch +pwm-sprd-explicitly-set-.polarity-in-.get_state.patch +kvm-s390-pv-fix-external-interruption-loop-not-alway.patch +wifi-mac80211-fix-invalid-drv_sta_pre_rcu_remove-cal.patch +net-qrtr-combine-nameservice-into-main-module.patch +net-qrtr-fix-a-refcount-bug-in-qrtr_recvmsg.patch +icmp-guard-against-too-small-mtu.patch +net-don-t-let-netpoll-invoke-napi-if-in-xmit-context.patch +sctp-check-send-stream-number-after-wait_for_sndbuf.patch +net-qrtr-do-not-do-del_server-broadcast-after-del_cl.patch +ipv6-fix-an-uninit-variable-access-bug-in-__ip6_make.patch +gpio-davinci-add-irq-chip-flag-to-skip-set-wake.patch +net-ethernet-ti-am65-cpsw-fix-mdio-cleanup-in-probe.patch +net-stmmac-fix-up-rx-flow-hash-indirection-table-whe.patch +sunrpc-only-free-unix-grouplist-after-rcu-settles.patch +nfsd-callback-request-does-not-use-correct-credentia.patch diff --git a/queue-5.10/sunrpc-only-free-unix-grouplist-after-rcu-settles.patch b/queue-5.10/sunrpc-only-free-unix-grouplist-after-rcu-settles.patch new file mode 100644 index 00000000000..e80ee8aabe1 --- /dev/null +++ b/queue-5.10/sunrpc-only-free-unix-grouplist-after-rcu-settles.patch @@ -0,0 +1,58 @@ +From 72c35ca83c5b459d6a7368229ae0a0d8a66e2d68 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 30 Mar 2023 14:24:27 -0400 +Subject: sunrpc: only free unix grouplist after RCU settles + +From: Jeff Layton + +[ Upstream commit 5085e41f9e83a1bec51da1f20b54f2ec3a13a3fe ] + +While the unix_gid object is rcu-freed, the group_info list that it +contains is not. Ensure that we only put the group list reference once +we are really freeing the unix_gid object. + +Reported-by: Zhi Li +Link: https://bugzilla.redhat.com/show_bug.cgi?id=2183056 +Signed-off-by: Jeff Layton +Fixes: fd5d2f78261b ("SUNRPC: Make server side AUTH_UNIX use lockless lookups") +Signed-off-by: Chuck Lever +Signed-off-by: Sasha Levin +--- + net/sunrpc/svcauth_unix.c | 17 +++++++++++++---- + 1 file changed, 13 insertions(+), 4 deletions(-) + +diff --git a/net/sunrpc/svcauth_unix.c b/net/sunrpc/svcauth_unix.c +index 97c0bddba7a30..60754a292589b 100644 +--- a/net/sunrpc/svcauth_unix.c ++++ b/net/sunrpc/svcauth_unix.c +@@ -424,14 +424,23 @@ static int unix_gid_hash(kuid_t uid) + return hash_long(from_kuid(&init_user_ns, uid), GID_HASHBITS); + } + +-static void unix_gid_put(struct kref *kref) ++static void unix_gid_free(struct rcu_head *rcu) + { +- struct cache_head *item = container_of(kref, struct cache_head, ref); +- struct unix_gid *ug = container_of(item, struct unix_gid, h); ++ struct unix_gid *ug = container_of(rcu, struct unix_gid, rcu); ++ struct cache_head *item = &ug->h; ++ + if (test_bit(CACHE_VALID, &item->flags) && + !test_bit(CACHE_NEGATIVE, &item->flags)) + put_group_info(ug->gi); +- kfree_rcu(ug, rcu); ++ kfree(ug); ++} ++ ++static void unix_gid_put(struct kref *kref) ++{ ++ struct cache_head *item = container_of(kref, struct cache_head, ref); ++ struct unix_gid *ug = container_of(item, struct unix_gid, h); ++ ++ call_rcu(&ug->rcu, unix_gid_free); + } + + static int unix_gid_match(struct cache_head *corig, struct cache_head *cnew) +-- +2.39.2 + diff --git a/queue-5.10/wifi-mac80211-fix-invalid-drv_sta_pre_rcu_remove-cal.patch b/queue-5.10/wifi-mac80211-fix-invalid-drv_sta_pre_rcu_remove-cal.patch new file mode 100644 index 00000000000..39535631266 --- /dev/null +++ b/queue-5.10/wifi-mac80211-fix-invalid-drv_sta_pre_rcu_remove-cal.patch @@ -0,0 +1,40 @@ +From b47eac4e738476728e0f323e2d126563a6e98061 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 24 Mar 2023 13:09:24 +0100 +Subject: wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for + non-uploaded sta + +From: Felix Fietkau + +[ Upstream commit 12b220a6171faf10638ab683a975cadcf1a352d6 ] + +Avoid potential data corruption issues caused by uninitialized driver +private data structures. + +Reported-by: Brian Coverstone +Fixes: 6a9d1b91f34d ("mac80211: add pre-RCU-sync sta removal driver operation") +Signed-off-by: Felix Fietkau +Link: https://lore.kernel.org/r/20230324120924.38412-3-nbd@nbd.name +Signed-off-by: Johannes Berg +Signed-off-by: Sasha Levin +--- + net/mac80211/sta_info.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c +index d572478c4d68e..2e84360990f0c 100644 +--- a/net/mac80211/sta_info.c ++++ b/net/mac80211/sta_info.c +@@ -1040,7 +1040,8 @@ static int __must_check __sta_info_destroy_part1(struct sta_info *sta) + list_del_rcu(&sta->list); + sta->removed = true; + +- drv_sta_pre_rcu_remove(local, sta->sdata, sta); ++ if (sta->uploaded) ++ drv_sta_pre_rcu_remove(local, sta->sdata, sta); + + if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN && + rcu_access_pointer(sdata->u.vlan.sta) == sta) +-- +2.39.2 +