Re: Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.6-stable tree

Re: Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.6-stable tree

[Michael S. Tsirkin]

On Fri, May 15, 2026 at 05:21:53PM +0200, gregkh@linuxfoundation.org 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.6-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.6 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.
> 

Yea I have some doubts. It fixes the DoS at the cost of losing
messages. We are trying to fix that upstream now, maybe wait
for that?


> >From 059b7dbd20a6f0c539a45ddff1573cb8946685b5 Mon Sep 17 00:00:00 2001
> From: Eric Dumazet <edumazet@google.com>
> Date: Thu, 30 Apr 2026 12:26:52 +0000
> Subject: vsock/virtio: fix potential unbounded skb queue
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> From: Eric Dumazet <edumazet@google.com>
> 
> commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream.
> 
> 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>
> [LL: Fixed conflict since this tree does not use buf_used added by commit
>  45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets")]
> Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  net/vmw_vsock/virtio_transport_common.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -283,7 +283,9 @@ static int virtio_transport_send_pkt_inf
>  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;
> 
> 
> Patches currently in stable-queue which might be from edumazet@google.com are
> 
> queue-6.6/net-fix-icmp-host-relookup-triggering-ip_rt_bug.patch
> queue-6.6/tcp-call-sk_data_ready-after-listener-migration.patch
> queue-6.6/net-sched-sch_red-replace-direct-dequeue-call-with-peek-and-qdisc_dequeue_peeked.patch
> queue-6.6/ip6_gre-use-cached-t-net-in-ip6erspan_changelink.patch
> queue-6.6/vsock-virtio-fix-potential-unbounded-skb-queue.patch

Re: Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.6-stable tree

[Greg KH]

On Fri, May 15, 2026 at 11:36:12AM -0400, Michael S. Tsirkin wrote:
> On Fri, May 15, 2026 at 05:21:53PM +0200, gregkh@linuxfoundation.org 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.6-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.6 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.
> > 
> 
> Yea I have some doubts. It fixes the DoS at the cost of losing
> messages. We are trying to fix that upstream now, maybe wait
> for that?

being bug compatible is good!  :(

What's the status of that fix?  Should it be reverted elsewhere?

thanks,

greg k-h

Re: Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.6-stable tree

[Michael S. Tsirkin]

On Fri, May 15, 2026 at 05:41:48PM +0200, Greg KH wrote:
> On Fri, May 15, 2026 at 11:36:12AM -0400, Michael S. Tsirkin wrote:
> > On Fri, May 15, 2026 at 05:21:53PM +0200, gregkh@linuxfoundation.org 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.6-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.6 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.
> > > 
> > 
> > Yea I have some doubts. It fixes the DoS at the cost of losing
> > messages. We are trying to fix that upstream now, maybe wait
> > for that?
> 
> being bug compatible is good!  :(

Well you are the maintainer. Up to you.

> What's the status of that fix?
> 
> thanks,
> 
> greg k-h


Stefano posted v3 and is working on v4.

>  Should it be reverted elsewhere?

Donnu. With the change we have no DoS but the socket gets silently
broken.  Eric felt given the brokenness is  upstream already it's better
to work on a fix on top, not revert.

-- 
MST