* Re: Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.1-stable tree
[not found] <20261018131321.3798770-1-sashal@kernel.org>
@ 2026-10-19 13:48 ` Stefano Garzarella
2026-10-19 16:54 ` Sasha Levin
0 siblings, 1 reply; 2+ messages in thread
From: Stefano Garzarella @ 2026-10-19 13:48 UTC (permalink / raw)
To: stable
Cc: stable-commits, edumazet, Michael S. Tsirkin, Jason Wang,
Eugenio Pérez, Xuan Zhuo, Stefan Hajnoczi, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman
On Sun, Oct 18, 2026 at 09:13:20AM -0400, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> vsock/virtio: fix potential unbounded skb queue
>
> to the 6.1-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> vsock-virtio-fix-potential-unbounded-skb-queue.patch
> and it can be found in the queue-6.1 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
Be careful with this patch, this caused data loss. It's fixed upstream
by commits:
a4f0b001782b ("vsock/virtio: reset connection on receiving queue
overflow")
2a12c05aef21 ("vsock/virtio: collapse receive queue under memory
pressure")
c6087c5aaad6 ("vsock/virtio: fix skb overhead accounting to preserve
full buf_alloc")
So if you want to backport this patch, I strongly recommend that you
include these others as well in the same backport.
Thanks,
Stefano
>
>
>
> commit 86c46b1c51eea22456caf8a28a43ccc3da623f01
> Author: Eric Dumazet <edumazet@kernel.org>
> Date: Thu Apr 30 12:26:52 2026 +0000
>
> vsock/virtio: fix potential unbounded skb queue
>
> [ Upstream commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 ]
>
> virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
>
> virtio_transport_recv_enqueue() skips coalescing for packets
> with VIRTIO_VSOCK_SEQ_EOM.
>
> If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
> a very large number of packets can be queued
> because vvs->rx_bytes stays at 0.
>
> Fix this by estimating the skb metadata size:
>
> (Number of skbs in the queue) * SKB_TRUESIZE(0)
>
> Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Stefano Garzarella <sgarzare@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: "Eugenio Pérez" <eperezma@redhat.com>
> Cc: virtualization@lists.linux.dev
> Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 6ea00b8630351..12d5844d98e39 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -254,7 +254,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> u32 len)
> {
> - if (vvs->rx_bytes + len > vvs->buf_alloc)
> + u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
> +
> + if (skb_overhead + vvs->rx_bytes + len > vvs->buf_alloc)
> return false;
>
> vvs->rx_bytes += len;
>
^ permalink raw reply [flat|nested] 2+ messages in thread