From: Jakub Kicinski <kuba@kernel.org>
To: Eric Dumazet <edumazet@google.com>
Cc: "Stefano Garzarella" <sgarzare@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Arseniy Krasnov" <avkrasnov@salutedevices.com>,
"Bobby Eshleman" <bobbyeshleman@meta.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"David S . Miller" <davem@davemloft.net>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
netdev@vger.kernel.org, eric.dumazet@gmail.com,
"Arseniy Krasnov" <AVKrasnov@sberdevices.ru>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
kvm@vger.kernel.org, virtualization@lists.linux.dev
Subject: Re: [PATCH net] vsock/virtio: fix potential unbounded skb queue
Date: Thu, 7 May 2026 10:18:05 -0700 [thread overview]
Message-ID: <20260507101805.6c3335d0@kernel.org> (raw)
In-Reply-To: <CANn89iJ+qOFPSUACvda7djOVKGM8t+FfwdA5Ymjxe+g_tJtmnA@mail.gmail.com>
On Thu, 7 May 2026 09:32:24 -0700 Eric Dumazet wrote:
> On Thu, May 7, 2026 at 9:05 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
> > On Thu, May 07, 2026 at 07:33:40AM -0700, Jakub Kicinski wrote:
> > >We can revert if you think that the risk of regression is high..
> > >Please LMK soon, we can do it before patch reaches Linus.
> >
> > Some tests in tools/testing/vsock/vsock_test.c are failing with this
> > patch applied.
> >
> > Test 18 are failing sometime in this way (I guess because we are
> > dropping packets):
> >
> > 18 - SOCK_STREAM MSG_ZEROCOPY...hash mismatch
> >
> > Test 22 is failing 100% in this way:
> >
> > 22 - SOCK_STREAM virtio credit update + SO_RCVLOWAT...send failed:
> > Resource temporarily unavailable
> >
> >
> > With my followup patch adding also advertisement to the other peer
> > (still draft locally, waiting for Michael proposal) I saw 22 failing,
> > because tests expects that can use the entire buf_alloc, but now we are
> > reducing it. So IMO we should do like in `__sock_set_rcvbuf()` and
> > double the buffer size, or at least digest an overhead equal to the
> > buffer size set by the user via SO_VM_SOCKETS_BUFFER_SIZE (yeah,
> > AF_VSOCK has it owns sockopt since the beginning :-().
> >
> > With that approach tests are passing, but I'd like to stress a bit more
> > that patch. I'll send it tomorrow as fixup of this patch, or if you
> > prefer to revert, I'll send as standalone.
>
> A plain revert is a big issue, now users now how to crash hypervisors.
>
> This vulnerability allows a compromised guest (controlling
> virtio_vsock_hdr fields)
> to continuously flood the host's vsock receive queue without
> triggering any memory
> accounting limits or reader wakeups, resulting in unbounded host
> kernel memory consumption (Host DoS via OOM).
>
> A vulnerability where a KVM guest can crash or deadlock its host is
> classified as a KVM DoS.
>
> Am I missing something?
Alright, let's leave it.
next prev parent reply other threads:[~2026-05-07 17:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 12:26 [PATCH net] vsock/virtio: fix potential unbounded skb queue Eric Dumazet
2026-05-05 2:20 ` patchwork-bot+netdevbpf
2026-05-05 13:51 ` Stefano Garzarella
2026-05-05 14:14 ` Eric Dumazet
2026-05-05 16:11 ` Stefano Garzarella
2026-05-05 16:37 ` Bobby Eshleman
2026-05-06 9:50 ` Arseniy Krasnov
2026-05-06 14:00 ` Stefano Garzarella
2026-05-06 15:37 ` Michael S. Tsirkin
2026-05-07 9:09 ` Stefano Garzarella
2026-05-07 11:45 ` Michael S. Tsirkin
2026-05-07 12:59 ` Stefano Garzarella
2026-05-07 14:33 ` Jakub Kicinski
2026-05-07 16:05 ` Stefano Garzarella
2026-05-07 16:32 ` Eric Dumazet
2026-05-07 17:18 ` Jakub Kicinski [this message]
2026-05-08 9:26 ` Stefano Garzarella
2026-05-07 14:52 ` Michael S. Tsirkin
2026-05-07 22:48 ` Michael S. Tsirkin
2026-05-08 9:41 ` Stefano Garzarella
2026-05-08 9:43 ` Michael S. Tsirkin
2026-05-08 9:58 ` Michael S. Tsirkin
2026-05-08 10:11 ` Stefano Garzarella
2026-05-23 21:00 ` Demi Marie Obenour
2026-05-25 2:37 ` Demi Marie Obenour
2026-05-25 9:14 ` Stefano Garzarella
2026-05-06 15:15 ` Michael S. Tsirkin
2026-05-06 15:38 ` Eric Dumazet
2026-05-06 15:49 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260507101805.6c3335d0@kernel.org \
--to=kuba@kernel.org \
--cc=AVKrasnov@sberdevices.ru \
--cc=avkrasnov@salutedevices.com \
--cc=bobbyeshleman@meta.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=horms@kernel.org \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.