From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: netdev@vger.kernel.org, "Simon Horman" <horms@kernel.org>,
"Eric Dumazet" <edumazet@google.com>,
"Arseniy Krasnov" <AVKrasnov@sberdevices.ru>,
"David S. Miller" <davem@davemloft.net>,
virtualization@lists.linux.dev, "Paolo Abeni" <pabeni@redhat.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
"Claudio Imbrenda" <imbrenda@linux.vnet.ibm.com>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Asias He" <asias@redhat.com>
Subject: Re: [PATCH net v6 0/4] vsock/virtio: fix TX credit handling
Date: Wed, 21 Jan 2026 07:35:53 -0500 [thread overview]
Message-ID: <20260121073547-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260121093628.9941-1-sgarzare@redhat.com>
On Wed, Jan 21, 2026 at 10:36:24AM +0100, Stefano Garzarella wrote:
> The original series was posted by Melbin K Mathew <mlbnkm1@gmail.com> till v4.
> Since it's a real issue and the original author seems busy, I'm sending
> the new version fixing my comments but keeping the authorship (and restoring
> mine on patch 2 as reported on v4).
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> v6:
> - Rebased on net tree since there was a conflict on patch 4 with another
> test added.
> - No code changes.
>
> v5: https://lore.kernel.org/netdev/20260116201517.273302-1-sgarzare@redhat.com/
> v4: https://lore.kernel.org/netdev/20251217181206.3681159-1-mlbnkm1@gmail.com/
>
> >From Melbin K Mathew <mlbnkm1@gmail.com>:
>
> This series fixes TX credit handling in virtio-vsock:
>
> Patch 1: Fix potential underflow in get_credit() using s64 arithmetic
> Patch 2: Fix vsock_test seqpacket bounds test
> Patch 3: Cap TX credit to local buffer size (security hardening)
> Patch 4: Add stream TX credit bounds regression test
>
> The core issue is that a malicious guest can advertise a huge buffer
> size via SO_VM_SOCKETS_BUFFER_SIZE, causing the host to allocate
> excessive sk_buff memory when sending data to that guest.
>
> On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with
> 32 guest vsock connections advertising 2 GiB each and reading slowly
> drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only
> recovered after killing the QEMU process.
>
> With this series applied, the same PoC shows only ~35 MiB increase in
> Slab/SUnreclaim, no host OOM, and the guest remains responsive.
>
> Melbin K Mathew (3):
> vsock/virtio: fix potential underflow in virtio_transport_get_credit()
> vsock/virtio: cap TX credit to local buffer size
> vsock/test: add stream TX credit bounds test
>
> Stefano Garzarella (1):
> vsock/test: fix seqpacket message bounds test
>
> net/vmw_vsock/virtio_transport_common.c | 30 +++++--
> tools/testing/vsock/vsock_test.c | 112 ++++++++++++++++++++++++
> 2 files changed, 133 insertions(+), 9 deletions(-)
>
> --
> 2.52.0
next prev parent reply other threads:[~2026-01-21 12:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 9:36 [PATCH net v6 0/4] vsock/virtio: fix TX credit handling Stefano Garzarella
2026-01-21 9:36 ` [PATCH net v6 1/4] vsock/virtio: fix potential underflow in virtio_transport_get_credit() Stefano Garzarella
2026-01-21 12:07 ` Luigi Leonardi
2026-01-21 9:36 ` [PATCH net v6 2/4] vsock/test: fix seqpacket message bounds test Stefano Garzarella
2026-01-21 9:36 ` [PATCH net v6 3/4] vsock/virtio: cap TX credit to local buffer size Stefano Garzarella
2026-01-21 12:10 ` Luigi Leonardi
2026-01-21 9:36 ` [PATCH net v6 4/4] vsock/test: add stream TX credit bounds test Stefano Garzarella
2026-01-21 12:35 ` Michael S. Tsirkin [this message]
2026-01-22 14:50 ` [PATCH net v6 0/4] vsock/virtio: fix TX credit handling patchwork-bot+netdevbpf
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=20260121073547-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=AVKrasnov@sberdevices.ru \
--cc=asias@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=horms@kernel.org \
--cc=imbrenda@linux.vnet.ibm.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.