]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 4.19
authorSasha Levin <sashal@kernel.org>
Sun, 9 Apr 2023 12:31:06 +0000 (08:31 -0400)
committerSasha Levin <sashal@kernel.org>
Sun, 9 Apr 2023 12:31:06 +0000 (08:31 -0400)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.19/gpio-davinci-add-irq-chip-flag-to-skip-set-wake.patch [new file with mode: 0644]
queue-4.19/icmp-guard-against-too-small-mtu.patch [new file with mode: 0644]
queue-4.19/ipv6-fix-an-uninit-variable-access-bug-in-__ip6_make.patch [new file with mode: 0644]
queue-4.19/net-don-t-let-netpoll-invoke-napi-if-in-xmit-context.patch [new file with mode: 0644]
queue-4.19/pwm-cros-ec-explicitly-set-.polarity-in-.get_state.patch [new file with mode: 0644]
queue-4.19/sctp-check-send-stream-number-after-wait_for_sndbuf.patch [new file with mode: 0644]
queue-4.19/series
queue-4.19/wifi-mac80211-fix-invalid-drv_sta_pre_rcu_remove-cal.patch [new file with mode: 0644]

diff --git a/queue-4.19/gpio-davinci-add-irq-chip-flag-to-skip-set-wake.patch b/queue-4.19/gpio-davinci-add-irq-chip-flag-to-skip-set-wake.patch
new file mode 100644 (file)
index 0000000..9c876c4
--- /dev/null
@@ -0,0 +1,37 @@
+From 29707b0c91ae84ae6b5463cd7dc0f63f6d8b5ef9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 3 Apr 2023 12:54:43 +0530
+Subject: gpio: davinci: Add irq chip flag to skip set wake
+
+From: Dhruva Gole <d-gole@ti.com>
+
+[ 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 <d-gole@ti.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 abb332d15a131..ead75c1062fbc 100644
+--- a/drivers/gpio/gpio-davinci.c
++++ b/drivers/gpio/gpio-davinci.c
+@@ -327,7 +327,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-4.19/icmp-guard-against-too-small-mtu.patch b/queue-4.19/icmp-guard-against-too-small-mtu.patch
new file mode 100644 (file)
index 0000000..33ff595
--- /dev/null
@@ -0,0 +1,86 @@
+From aa42eb869d3dff00f218a22a0ff9e9ac1811b7d2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 30 Mar 2023 17:45:02 +0000
+Subject: icmp: guard against too small mtu
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ 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:
+<IRQ>
+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 <edumazet@google.com>
+Link: https://lore.kernel.org/r/20230330174502.1915328-1-edumazet@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/icmp.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
+index aa179e6461e17..af0ddaa55e431 100644
+--- a/net/ipv4/icmp.c
++++ b/net/ipv4/icmp.c
+@@ -759,6 +759,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-4.19/ipv6-fix-an-uninit-variable-access-bug-in-__ip6_make.patch b/queue-4.19/ipv6-fix-an-uninit-variable-access-bug-in-__ip6_make.patch
new file mode 100644 (file)
index 0000000..72a01fa
--- /dev/null
@@ -0,0 +1,101 @@
+From fe72ca1fc781740231cc5bb6c2fef414b2745690 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 3 Apr 2023 15:34:17 +0800
+Subject: ipv6: Fix an uninit variable access bug in __ip6_make_skb()
+
+From: Ziyang Xuan <william.xuanziyang@huawei.com>
+
+[ 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 <william.xuanziyang@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 70820d049b92a..4f31a781ab370 100644
+--- a/net/ipv6/ip6_output.c
++++ b/net/ipv6/ip6_output.c
+@@ -1730,8 +1730,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-4.19/net-don-t-let-netpoll-invoke-napi-if-in-xmit-context.patch b/queue-4.19/net-don-t-let-netpoll-invoke-napi-if-in-xmit-context.patch
new file mode 100644 (file)
index 0000000..06769e4
--- /dev/null
@@ -0,0 +1,80 @@
+From 0d24e5b0a1764332bef177410c3b30f4f41ca420 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 30 Mar 2023 19:21:44 -0700
+Subject: net: don't let netpoll invoke NAPI if in xmit context
+
+From: Jakub Kicinski <kuba@kernel.org>
+
+[ 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 <roman.gushchin@linux.dev>
+Fixes: 0db3dc73f7a3 ("[NETPOLL]: tx lock deadlock fix")
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 41e32a958d08d..08f0da9e6a809 100644
+--- a/net/core/netpoll.c
++++ b/net/core/netpoll.c
+@@ -136,6 +136,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;
+@@ -182,7 +196,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-4.19/pwm-cros-ec-explicitly-set-.polarity-in-.get_state.patch b/queue-4.19/pwm-cros-ec-explicitly-set-.polarity-in-.get_state.patch
new file mode 100644 (file)
index 0000000..affe29a
--- /dev/null
@@ -0,0 +1,40 @@
+From 61fc49be27e8a2096f5e57446da37072771f526a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <u.kleine-koenig@pengutronix.de>
+
+[ Upstream commit 30006b77c7e130e01d1ab2148cc8abf73dfcc4bf ]
+
+The driver only supports normal polarity. Complete the implementation of
+.get_state() by setting .polarity accordingly.
+
+Reviewed-by: Guenter Roeck <groeck@chromium.org>
+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 <u.kleine-koenig@pengutronix.de>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 98f6ac6cf6ab4..bedf6298acfbb 100644
+--- a/drivers/pwm/pwm-cros-ec.c
++++ b/drivers/pwm/pwm-cros-ec.c
+@@ -125,6 +125,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 */
+       state->duty_cycle = ret;
+-- 
+2.39.2
+
diff --git a/queue-4.19/sctp-check-send-stream-number-after-wait_for_sndbuf.patch b/queue-4.19/sctp-check-send-stream-number-after-wait_for_sndbuf.patch
new file mode 100644 (file)
index 0000000..53347bc
--- /dev/null
@@ -0,0 +1,66 @@
+From b958f515b75451e4b7259700f46d49b38ddbab32 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 1 Apr 2023 19:09:57 -0400
+Subject: sctp: check send stream number after wait_for_sndbuf
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ 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:
+   <TASK>
+   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 <lucien.xin@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sctp/socket.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/net/sctp/socket.c b/net/sctp/socket.c
+index 8901bb7afa2be..355b89579e930 100644
+--- a/net/sctp/socket.c
++++ b/net/sctp/socket.c
+@@ -1953,6 +1953,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
+
index 1eb695cf53dd0d06ed6de3b5fe2bc445ff027c12..3611c8a15c6589e3bfc259e58ab2a695abf746bc 100644 (file)
@@ -5,3 +5,10 @@ pinctrl-amd-disable-and-mask-interrupts-on-resume.patch
 nfsv4-convert-struct-nfs4_state-to-use-refcount_t.patch
 nfsv4-check-the-return-value-of-update_open_stateid.patch
 nfsv4-fix-hangs-when-recovering-open-state-after-a-s.patch
+pwm-cros-ec-explicitly-set-.polarity-in-.get_state.patch
+wifi-mac80211-fix-invalid-drv_sta_pre_rcu_remove-cal.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
+ipv6-fix-an-uninit-variable-access-bug-in-__ip6_make.patch
+gpio-davinci-add-irq-chip-flag-to-skip-set-wake.patch
diff --git a/queue-4.19/wifi-mac80211-fix-invalid-drv_sta_pre_rcu_remove-cal.patch b/queue-4.19/wifi-mac80211-fix-invalid-drv_sta_pre_rcu_remove-cal.patch
new file mode 100644 (file)
index 0000000..edf0616
--- /dev/null
@@ -0,0 +1,40 @@
+From f6a3d7630b00c77fccae81f5f3f1dcadc628e1fb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <nbd@nbd.name>
+
+[ Upstream commit 12b220a6171faf10638ab683a975cadcf1a352d6 ]
+
+Avoid potential data corruption issues caused by uninitialized driver
+private data structures.
+
+Reported-by: Brian Coverstone <brian@mainsequence.net>
+Fixes: 6a9d1b91f34d ("mac80211: add pre-RCU-sync sta removal driver operation")
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Link: https://lore.kernel.org/r/20230324120924.38412-3-nbd@nbd.name
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 5e28be07cad88..5c209f72de701 100644
+--- a/net/mac80211/sta_info.c
++++ b/net/mac80211/sta_info.c
+@@ -969,7 +969,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
+