From 38ebda2275c321b2b04632de8037d92bb8e89756 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 15 Nov 2023 15:22:11 -0500 Subject: [PATCH] 6.1-stable patches added patches: virtio-vsock-don-t-drop-skbuff-on-copy-failure.patch virtio-vsock-don-t-use-skbuff-state-to-account-credit.patch virtio-vsock-fix-header-length-on-skb-merging.patch virtio-vsock-fix-leaks-due-to-missing-skb-owner.patch virtio-vsock-fix-uninit-value-in-virtio_transport_recv_pkt.patch virtio-vsock-remove-redundant-skb_pull-call.patch vsock-loopback-use-only-sk_buff_head.lock-to-protect-the-packet-queue.patch wifi-cfg80211-fix-kernel-doc-for-wiphy_delayed_work_flush.patch --- queue-6.1/series | 8 ++ ...ck-don-t-drop-skbuff-on-copy-failure.patch | 47 ++++++++ ...t-use-skbuff-state-to-account-credit.patch | 113 ++++++++++++++++++ ...ock-fix-header-length-on-skb-merging.patch | 46 +++++++ ...k-fix-leaks-due-to-missing-skb-owner.patch | 57 +++++++++ ...t-value-in-virtio_transport_recv_pkt.patch | 101 ++++++++++++++++ ...vsock-remove-redundant-skb_pull-call.patch | 33 +++++ ...ead.lock-to-protect-the-packet-queue.patch | 85 +++++++++++++ ...nel-doc-for-wiphy_delayed_work_flush.patch | 31 +++++ 9 files changed, 521 insertions(+) create mode 100644 queue-6.1/virtio-vsock-don-t-drop-skbuff-on-copy-failure.patch create mode 100644 queue-6.1/virtio-vsock-don-t-use-skbuff-state-to-account-credit.patch create mode 100644 queue-6.1/virtio-vsock-fix-header-length-on-skb-merging.patch create mode 100644 queue-6.1/virtio-vsock-fix-leaks-due-to-missing-skb-owner.patch create mode 100644 queue-6.1/virtio-vsock-fix-uninit-value-in-virtio_transport_recv_pkt.patch create mode 100644 queue-6.1/virtio-vsock-remove-redundant-skb_pull-call.patch create mode 100644 queue-6.1/vsock-loopback-use-only-sk_buff_head.lock-to-protect-the-packet-queue.patch create mode 100644 queue-6.1/wifi-cfg80211-fix-kernel-doc-for-wiphy_delayed_work_flush.patch diff --git a/queue-6.1/series b/queue-6.1/series index 7cdd202cf24..09004dfb72d 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -377,3 +377,11 @@ io_uring-net-ensure-socket-is-marked-connected-on-connect-retry.patch x86-amd_nb-use-family-19h-models-60h-7fh-function-4-ids.patch revert-mmc-core-capture-correct-oemid-bits-for-emmc-cards.patch btrfs-use-u64-for-buffer-sizes-in-the-tree-search-io.patch +wifi-cfg80211-fix-kernel-doc-for-wiphy_delayed_work_flush.patch +virtio-vsock-don-t-use-skbuff-state-to-account-credit.patch +virtio-vsock-remove-redundant-skb_pull-call.patch +virtio-vsock-don-t-drop-skbuff-on-copy-failure.patch +vsock-loopback-use-only-sk_buff_head.lock-to-protect-the-packet-queue.patch +virtio-vsock-fix-leaks-due-to-missing-skb-owner.patch +virtio-vsock-fix-uninit-value-in-virtio_transport_recv_pkt.patch +virtio-vsock-fix-header-length-on-skb-merging.patch diff --git a/queue-6.1/virtio-vsock-don-t-drop-skbuff-on-copy-failure.patch b/queue-6.1/virtio-vsock-don-t-drop-skbuff-on-copy-failure.patch new file mode 100644 index 00000000000..194322b18d0 --- /dev/null +++ b/queue-6.1/virtio-vsock-don-t-drop-skbuff-on-copy-failure.patch @@ -0,0 +1,47 @@ +From 8daaf39f7f6ef53a11817f6a11ec104016c3545f Mon Sep 17 00:00:00 2001 +From: Arseniy Krasnov +Date: Tue, 14 Mar 2023 14:08:20 +0300 +Subject: virtio/vsock: don't drop skbuff on copy failure + +From: Arseniy Krasnov + +commit 8daaf39f7f6ef53a11817f6a11ec104016c3545f upstream. + +This returns behaviour of SOCK_STREAM read as before skbuff usage. When +copying to user fails current skbuff won't be dropped, but returned to +sockets's queue. Technically instead of 'skb_dequeue()', 'skb_peek()' is +called and when skbuff becomes empty, it is removed from queue by +'__skb_unlink()'. + +Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") +Signed-off-by: Arseniy Krasnov +Reviewed-by: Stefano Garzarella +Acked-by: Bobby Eshleman +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/virtio_transport_common.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/net/vmw_vsock/virtio_transport_common.c ++++ b/net/vmw_vsock/virtio_transport_common.c +@@ -364,7 +364,7 @@ virtio_transport_stream_do_dequeue(struc + + spin_lock_bh(&vvs->rx_lock); + while (total < len && !skb_queue_empty(&vvs->rx_queue)) { +- skb = __skb_dequeue(&vvs->rx_queue); ++ skb = skb_peek(&vvs->rx_queue); + + bytes = len - total; + if (bytes > skb->len) +@@ -388,9 +388,8 @@ virtio_transport_stream_do_dequeue(struc + u32 pkt_len = le32_to_cpu(virtio_vsock_hdr(skb)->len); + + virtio_transport_dec_rx_pkt(vvs, pkt_len); ++ __skb_unlink(skb, &vvs->rx_queue); + consume_skb(skb); +- } else { +- __skb_queue_head(&vvs->rx_queue, skb); + } + } + diff --git a/queue-6.1/virtio-vsock-don-t-use-skbuff-state-to-account-credit.patch b/queue-6.1/virtio-vsock-don-t-use-skbuff-state-to-account-credit.patch new file mode 100644 index 00000000000..4dd8ff79491 --- /dev/null +++ b/queue-6.1/virtio-vsock-don-t-use-skbuff-state-to-account-credit.patch @@ -0,0 +1,113 @@ +From 077706165717686a2a6a71405fef036cd5b37ae0 Mon Sep 17 00:00:00 2001 +From: Arseniy Krasnov +Date: Tue, 14 Mar 2023 14:05:48 +0300 +Subject: virtio/vsock: don't use skbuff state to account credit + +From: Arseniy Krasnov + +commit 077706165717686a2a6a71405fef036cd5b37ae0 upstream. + +'skb->len' can vary when we partially read the data, this complicates the +calculation of credit to be updated in 'virtio_transport_inc_rx_pkt()/ +virtio_transport_dec_rx_pkt()'. + +Also in 'virtio_transport_dec_rx_pkt()' we were miscalculating the +credit since 'skb->len' was redundant. + +For these reasons, let's replace the use of skbuff state to calculate new +'rx_bytes'/'fwd_cnt' values with explicit value as input argument. This +makes code more simple, because it is not needed to change skbuff state +before each call to update 'rx_bytes'/'fwd_cnt'. + +Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") +Signed-off-by: Arseniy Krasnov +Reviewed-by: Stefano Garzarella +Acked-by: Bobby Eshleman +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/virtio_transport_common.c | 23 +++++++++++------------ + 1 file changed, 11 insertions(+), 12 deletions(-) + +diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c +index a1581c77cf84..618680fd9906 100644 +--- a/net/vmw_vsock/virtio_transport_common.c ++++ b/net/vmw_vsock/virtio_transport_common.c +@@ -241,21 +241,18 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk, + } + + static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs, +- struct sk_buff *skb) ++ u32 len) + { +- if (vvs->rx_bytes + skb->len > vvs->buf_alloc) ++ if (vvs->rx_bytes + len > vvs->buf_alloc) + return false; + +- vvs->rx_bytes += skb->len; ++ vvs->rx_bytes += len; + return true; + } + + static void virtio_transport_dec_rx_pkt(struct virtio_vsock_sock *vvs, +- struct sk_buff *skb) ++ u32 len) + { +- int len; +- +- len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr) - skb->len; + vvs->rx_bytes -= len; + vvs->fwd_cnt += len; + } +@@ -388,7 +385,9 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk, + skb_pull(skb, bytes); + + if (skb->len == 0) { +- virtio_transport_dec_rx_pkt(vvs, skb); ++ u32 pkt_len = le32_to_cpu(virtio_vsock_hdr(skb)->len); ++ ++ virtio_transport_dec_rx_pkt(vvs, pkt_len); + consume_skb(skb); + } else { + __skb_queue_head(&vvs->rx_queue, skb); +@@ -437,17 +436,17 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk, + + while (!msg_ready) { + struct virtio_vsock_hdr *hdr; ++ size_t pkt_len; + + skb = __skb_dequeue(&vvs->rx_queue); + if (!skb) + break; + hdr = virtio_vsock_hdr(skb); ++ pkt_len = (size_t)le32_to_cpu(hdr->len); + + if (dequeued_len >= 0) { +- size_t pkt_len; + size_t bytes_to_copy; + +- pkt_len = (size_t)le32_to_cpu(hdr->len); + bytes_to_copy = min(user_buf_len, pkt_len); + + if (bytes_to_copy) { +@@ -484,7 +483,7 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk, + msg->msg_flags |= MSG_EOR; + } + +- virtio_transport_dec_rx_pkt(vvs, skb); ++ virtio_transport_dec_rx_pkt(vvs, pkt_len); + kfree_skb(skb); + } + +@@ -1040,7 +1039,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, + + spin_lock_bh(&vvs->rx_lock); + +- can_enqueue = virtio_transport_inc_rx_pkt(vvs, skb); ++ can_enqueue = virtio_transport_inc_rx_pkt(vvs, len); + if (!can_enqueue) { + free_pkt = true; + goto out; +-- +2.42.1 + diff --git a/queue-6.1/virtio-vsock-fix-header-length-on-skb-merging.patch b/queue-6.1/virtio-vsock-fix-header-length-on-skb-merging.patch new file mode 100644 index 00000000000..45210404f4e --- /dev/null +++ b/queue-6.1/virtio-vsock-fix-header-length-on-skb-merging.patch @@ -0,0 +1,46 @@ +From f7154d967bc4ee25ea1572937550e711b2525474 Mon Sep 17 00:00:00 2001 +From: Arseniy Krasnov +Date: Tue, 28 Mar 2023 14:31:28 +0300 +Subject: virtio/vsock: fix header length on skb merging + +From: Arseniy Krasnov + +commit f7154d967bc4ee25ea1572937550e711b2525474 upstream. + +This fixes appending newly arrived skbuff to the last skbuff of the +socket's queue. Problem fires when we are trying to append data to skbuff +which was already processed in dequeue callback at least once. Dequeue +callback calls function 'skb_pull()' which changes 'skb->len'. In current +implementation 'skb->len' is used to update length in header of the last +skbuff after new data was copied to it. This is bug, because value in +header is used to calculate 'rx_bytes'/'fwd_cnt' and thus must be not +be changed during skbuff's lifetime. + +Bug starts to fire since: + +commit 077706165717 +("virtio/vsock: don't use skbuff state to account credit") + +It presents before, but didn't triggered due to a little bit buggy +implementation of credit calculation logic. So use Fixes tag for it. + +Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit") +Signed-off-by: Arseniy Krasnov +Reviewed-by: Stefano Garzarella +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/virtio_transport_common.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/vmw_vsock/virtio_transport_common.c ++++ b/net/vmw_vsock/virtio_transport_common.c +@@ -1075,7 +1075,7 @@ virtio_transport_recv_enqueue(struct vso + memcpy(skb_put(last_skb, skb->len), skb->data, skb->len); + free_pkt = true; + last_hdr->flags |= hdr->flags; +- last_hdr->len = cpu_to_le32(last_skb->len); ++ le32_add_cpu(&last_hdr->len, len); + goto out; + } + } diff --git a/queue-6.1/virtio-vsock-fix-leaks-due-to-missing-skb-owner.patch b/queue-6.1/virtio-vsock-fix-leaks-due-to-missing-skb-owner.patch new file mode 100644 index 00000000000..543e568f938 --- /dev/null +++ b/queue-6.1/virtio-vsock-fix-leaks-due-to-missing-skb-owner.patch @@ -0,0 +1,57 @@ +From f9d2b1e146e0f82f3d04629afd92698522058361 Mon Sep 17 00:00:00 2001 +From: Bobby Eshleman +Date: Wed, 29 Mar 2023 16:51:58 +0000 +Subject: virtio/vsock: fix leaks due to missing skb owner + +From: Bobby Eshleman + +commit f9d2b1e146e0f82f3d04629afd92698522058361 upstream. + +This patch sets the skb owner in the recv and send path for virtio. + +For the send path, this solves the leak caused when +virtio_transport_purge_skbs() finds skb->sk is always NULL and therefore +never matches it with the current socket. Setting the owner upon +allocation fixes this. + +For the recv path, this ensures correctness of accounting and also +correct transfer of ownership in vsock_loopback (when skbs are sent from +one socket and received by another). + +Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") +Signed-off-by: Bobby Eshleman +Reported-by: Cong Wang +Link: https://lore.kernel.org/all/ZCCbATwov4U+GBUv@pop-os.localdomain/ +Reviewed-by: Stefano Garzarella +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/virtio_transport_common.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/net/vmw_vsock/virtio_transport_common.c ++++ b/net/vmw_vsock/virtio_transport_common.c +@@ -94,6 +94,11 @@ virtio_transport_alloc_skb(struct virtio + info->op, + info->flags); + ++ if (info->vsk && !skb_set_owner_sk_safe(skb, sk_vsock(info->vsk))) { ++ WARN_ONCE(1, "failed to allocate skb on vsock socket with sk_refcnt == 0\n"); ++ goto out; ++ } ++ + return skb; + + out: +@@ -1302,6 +1307,11 @@ void virtio_transport_recv_pkt(struct vi + goto free_pkt; + } + ++ if (!skb_set_owner_sk_safe(skb, sk)) { ++ WARN_ONCE(1, "receiving vsock socket has sk_refcnt == 0\n"); ++ goto free_pkt; ++ } ++ + vsk = vsock_sk(sk); + + lock_sock(sk); diff --git a/queue-6.1/virtio-vsock-fix-uninit-value-in-virtio_transport_recv_pkt.patch b/queue-6.1/virtio-vsock-fix-uninit-value-in-virtio_transport_recv_pkt.patch new file mode 100644 index 00000000000..b9167da4ff8 --- /dev/null +++ b/queue-6.1/virtio-vsock-fix-uninit-value-in-virtio_transport_recv_pkt.patch @@ -0,0 +1,101 @@ +From 34c4effacfc329aeca5635a69fd9e0f6c90b4101 Mon Sep 17 00:00:00 2001 +From: Shigeru Yoshida +Date: Sun, 5 Nov 2023 00:05:31 +0900 +Subject: virtio/vsock: Fix uninit-value in virtio_transport_recv_pkt() + +From: Shigeru Yoshida + +commit 34c4effacfc329aeca5635a69fd9e0f6c90b4101 upstream. + +KMSAN reported the following uninit-value access issue: + +===================================================== +BUG: KMSAN: uninit-value in virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421 + virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421 + vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 + process_one_work kernel/workqueue.c:2630 [inline] + process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 + worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784 + kthread+0x3cc/0x520 kernel/kthread.c:388 + ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 + +Uninit was stored to memory at: + virtio_transport_space_update net/vmw_vsock/virtio_transport_common.c:1274 [inline] + virtio_transport_recv_pkt+0x1ee8/0x26a0 net/vmw_vsock/virtio_transport_common.c:1415 + vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 + process_one_work kernel/workqueue.c:2630 [inline] + process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 + worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784 + kthread+0x3cc/0x520 kernel/kthread.c:388 + ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 + +Uninit was created at: + slab_post_alloc_hook+0x105/0xad0 mm/slab.h:767 + slab_alloc_node mm/slub.c:3478 [inline] + kmem_cache_alloc_node+0x5a2/0xaf0 mm/slub.c:3523 + kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:559 + __alloc_skb+0x2fd/0x770 net/core/skbuff.c:650 + alloc_skb include/linux/skbuff.h:1286 [inline] + virtio_vsock_alloc_skb include/linux/virtio_vsock.h:66 [inline] + virtio_transport_alloc_skb+0x90/0x11e0 net/vmw_vsock/virtio_transport_common.c:58 + virtio_transport_reset_no_sock net/vmw_vsock/virtio_transport_common.c:957 [inline] + virtio_transport_recv_pkt+0x1279/0x26a0 net/vmw_vsock/virtio_transport_common.c:1387 + vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 + process_one_work kernel/workqueue.c:2630 [inline] + process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 + worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784 + kthread+0x3cc/0x520 kernel/kthread.c:388 + ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 + +CPU: 1 PID: 10664 Comm: kworker/1:5 Not tainted 6.6.0-rc3-00146-g9f3ebbef746f #3 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 +Workqueue: vsock-loopback vsock_loopback_work +===================================================== + +The following simple reproducer can cause the issue described above: + +int main(void) +{ + int sock; + struct sockaddr_vm addr = { + .svm_family = AF_VSOCK, + .svm_cid = VMADDR_CID_ANY, + .svm_port = 1234, + }; + + sock = socket(AF_VSOCK, SOCK_STREAM, 0); + connect(sock, (struct sockaddr *)&addr, sizeof(addr)); + return 0; +} + +This issue occurs because the `buf_alloc` and `fwd_cnt` fields of the +`struct virtio_vsock_hdr` are not initialized when a new skb is allocated +in `virtio_transport_init_hdr()`. This patch resolves the issue by +initializing these fields during allocation. + +Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") +Reported-and-tested-by: syzbot+0c8ce1da0ac31abbadcd@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=0c8ce1da0ac31abbadcd +Signed-off-by: Shigeru Yoshida +Reviewed-by: Stefano Garzarella +Link: https://lore.kernel.org/r/20231104150531.257952-1-syoshida@redhat.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/virtio_transport_common.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/vmw_vsock/virtio_transport_common.c ++++ b/net/vmw_vsock/virtio_transport_common.c +@@ -68,6 +68,8 @@ virtio_transport_alloc_skb(struct virtio + hdr->dst_port = cpu_to_le32(dst_port); + hdr->flags = cpu_to_le32(info->flags); + hdr->len = cpu_to_le32(len); ++ hdr->buf_alloc = cpu_to_le32(0); ++ hdr->fwd_cnt = cpu_to_le32(0); + + if (info->msg && len > 0) { + payload = skb_put(skb, len); diff --git a/queue-6.1/virtio-vsock-remove-redundant-skb_pull-call.patch b/queue-6.1/virtio-vsock-remove-redundant-skb_pull-call.patch new file mode 100644 index 00000000000..3dd67c02423 --- /dev/null +++ b/queue-6.1/virtio-vsock-remove-redundant-skb_pull-call.patch @@ -0,0 +1,33 @@ +From 6825e6b4f8e53799d83bc39ca6ec5baed4e2adde Mon Sep 17 00:00:00 2001 +From: Arseniy Krasnov +Date: Tue, 14 Mar 2023 14:06:53 +0300 +Subject: virtio/vsock: remove redundant 'skb_pull()' call + +From: Arseniy Krasnov + +commit 6825e6b4f8e53799d83bc39ca6ec5baed4e2adde upstream. + +Since we now no longer use 'skb->len' to update credit, there is no sense +to update skbuff state, because it is used only once after dequeue to +copy data and then will be released. + +Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") +Signed-off-by: Arseniy Krasnov +Reviewed-by: Stefano Garzarella +Acked-by: Bobby Eshleman +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/virtio_transport_common.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/net/vmw_vsock/virtio_transport_common.c ++++ b/net/vmw_vsock/virtio_transport_common.c +@@ -465,7 +465,6 @@ static int virtio_transport_seqpacket_do + dequeued_len = err; + } else { + user_buf_len -= bytes_to_copy; +- skb_pull(skb, bytes_to_copy); + } + + spin_lock_bh(&vvs->rx_lock); diff --git a/queue-6.1/vsock-loopback-use-only-sk_buff_head.lock-to-protect-the-packet-queue.patch b/queue-6.1/vsock-loopback-use-only-sk_buff_head.lock-to-protect-the-packet-queue.patch new file mode 100644 index 00000000000..031c697dbbb --- /dev/null +++ b/queue-6.1/vsock-loopback-use-only-sk_buff_head.lock-to-protect-the-packet-queue.patch @@ -0,0 +1,85 @@ +From b465518dc27da1ed74b8cbada4659708aac35adb Mon Sep 17 00:00:00 2001 +From: Stefano Garzarella +Date: Fri, 24 Mar 2023 12:54:50 +0100 +Subject: vsock/loopback: use only sk_buff_head.lock to protect the packet queue + +From: Stefano Garzarella + +commit b465518dc27da1ed74b8cbada4659708aac35adb upstream. + +pkt_list_lock was used before commit 71dc9ec9ac7d ("virtio/vsock: +replace virtio_vsock_pkt with sk_buff") to protect the packet queue. +After that commit we switched to sk_buff and we are using +sk_buff_head.lock in almost every place to protect the packet queue +except in vsock_loopback_work() when we call skb_queue_splice_init(). + +As reported by syzbot, this caused unlocked concurrent access to the +packet queue between vsock_loopback_work() and +vsock_loopback_cancel_pkt() since it is not holding pkt_list_lock. + +With the introduction of sk_buff_head, pkt_list_lock is redundant and +can cause confusion, so let's remove it and use sk_buff_head.lock +everywhere to protect the packet queue access. + +Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") +Cc: bobby.eshleman@bytedance.com +Reported-and-tested-by: syzbot+befff0a9536049e7902e@syzkaller.appspotmail.com +Signed-off-by: Stefano Garzarella +Reviewed-by: Bobby Eshleman +Reviewed-by: Arseniy Krasnov +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/vsock_loopback.c | 10 ++-------- + 1 file changed, 2 insertions(+), 8 deletions(-) + +--- a/net/vmw_vsock/vsock_loopback.c ++++ b/net/vmw_vsock/vsock_loopback.c +@@ -15,7 +15,6 @@ + struct vsock_loopback { + struct workqueue_struct *workqueue; + +- spinlock_t pkt_list_lock; /* protects pkt_list */ + struct sk_buff_head pkt_queue; + struct work_struct pkt_work; + }; +@@ -32,9 +31,7 @@ static int vsock_loopback_send_pkt(struc + struct vsock_loopback *vsock = &the_vsock_loopback; + int len = skb->len; + +- spin_lock_bh(&vsock->pkt_list_lock); + skb_queue_tail(&vsock->pkt_queue, skb); +- spin_unlock_bh(&vsock->pkt_list_lock); + + queue_work(vsock->workqueue, &vsock->pkt_work); + +@@ -113,9 +110,9 @@ static void vsock_loopback_work(struct w + + skb_queue_head_init(&pkts); + +- spin_lock_bh(&vsock->pkt_list_lock); ++ spin_lock_bh(&vsock->pkt_queue.lock); + skb_queue_splice_init(&vsock->pkt_queue, &pkts); +- spin_unlock_bh(&vsock->pkt_list_lock); ++ spin_unlock_bh(&vsock->pkt_queue.lock); + + while ((skb = __skb_dequeue(&pkts))) { + virtio_transport_deliver_tap_pkt(skb); +@@ -132,7 +129,6 @@ static int __init vsock_loopback_init(vo + if (!vsock->workqueue) + return -ENOMEM; + +- spin_lock_init(&vsock->pkt_list_lock); + skb_queue_head_init(&vsock->pkt_queue); + INIT_WORK(&vsock->pkt_work, vsock_loopback_work); + +@@ -156,9 +152,7 @@ static void __exit vsock_loopback_exit(v + + flush_work(&vsock->pkt_work); + +- spin_lock_bh(&vsock->pkt_list_lock); + virtio_vsock_skb_queue_purge(&vsock->pkt_queue); +- spin_unlock_bh(&vsock->pkt_list_lock); + + destroy_workqueue(vsock->workqueue); + } diff --git a/queue-6.1/wifi-cfg80211-fix-kernel-doc-for-wiphy_delayed_work_flush.patch b/queue-6.1/wifi-cfg80211-fix-kernel-doc-for-wiphy_delayed_work_flush.patch new file mode 100644 index 00000000000..b07daa07c1f --- /dev/null +++ b/queue-6.1/wifi-cfg80211-fix-kernel-doc-for-wiphy_delayed_work_flush.patch @@ -0,0 +1,31 @@ +From 8c73d5248dcf112611654bcd32352dc330b02397 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Wed, 13 Sep 2023 09:34:25 +0200 +Subject: wifi: cfg80211: fix kernel-doc for wiphy_delayed_work_flush() + +From: Johannes Berg + +commit 8c73d5248dcf112611654bcd32352dc330b02397 upstream. + +Clearly, there's no space in the function name, not sure how +that could've happened. Put the underscore that it should be. + +Reported-by: Stephen Rothwell +Fixes: 56cfb8ce1f7f ("wifi: cfg80211: add flush functions for wiphy work") +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + include/net/cfg80211.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/net/cfg80211.h ++++ b/include/net/cfg80211.h +@@ -5744,7 +5744,7 @@ void wiphy_delayed_work_cancel(struct wi + struct wiphy_delayed_work *dwork); + + /** +- * wiphy_delayed work_flush - flush previously queued delayed work ++ * wiphy_delayed_work_flush - flush previously queued delayed work + * @wiphy: the wiphy, for debug purposes + * @work: the work to flush + * -- 2.47.3