On Thu, Dec 11, 2025 at 01:51:04PM +0100, Melbin K Mathew wrote:

The virtio vsock transport currently derives its TX credit directly from
peer_buf_alloc, which is populated from the remote endpoint's
SO_VM_SOCKETS_BUFFER_SIZE value.

On the host side, this means the amount of data we are willing to queue
for a given connection is scaled purely by a peer-chosen value, rather
than by the host's own vsock buffer configuration. A guest that
advertises a very large buffer and reads slowly can cause the host to
allocate a correspondingly large amount of sk_buff memory for that
connection.

In practice, a malicious guest can:

 - set a large AF_VSOCK buffer size (e.g. 2 GiB) with
   SO_VM_SOCKETS_BUFFER_MAX_SIZE / SO_VM_SOCKETS_BUFFER_SIZE, and

 - open multiple connections to a host vsock service that sends data
   while the guest drains slowly.

On an unconstrained host this can drive Slab/SUnreclaim into the tens of
GiB range, causing allocation failures and OOM kills in unrelated host
processes while the offending VM remains running.

On non-virtio transports and compatibility:

 - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per
   socket based on the local vsk->buffer_* values; the remote side
   can’t enlarge those queues beyond what the local endpoint
   configured.

 - Hyper-V’s vsock transport uses fixed-size VMBus ring buffers and
   an MTU bound; there is no peer-controlled credit field comparable
   to peer_buf_alloc, and the remote endpoint can’t drive in-flight
   kernel memory above those ring sizes.

 - The loopback path reuses virtio_transport_common.c, so it
   naturally follows the same semantics as the virtio transport.

Make virtio-vsock consistent with that model by intersecting the peer’s
advertised receive window with the local vsock buffer size when
computing TX credit. We introduce a small helper and use it in
virtio_transport_get_credit(), virtio_transport_has_space() and
virtio_transport_seqpacket_enqueue(), so that:

   effective_tx_window = min(peer_buf_alloc, buf_alloc)

This prevents a remote endpoint from forcing us to queue more data than
our own configuration allows, while preserving the existing credit
semantics and keeping virtio-vsock compatible with the other transports.

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 and the system only
recovered after killing the QEMU process.

With this patch applied, rerunning the same PoC yields:

 Before:
   MemFree:        ~61.6 GiB
   MemAvailable:   ~62.3 GiB
   Slab:           ~142 MiB
   SUnreclaim:     ~117 MiB

 After 32 high-credit connections:
   MemFree:        ~61.5 GiB
   MemAvailable:   ~62.3 GiB
   Slab:           ~178 MiB
   SUnreclaim:     ~152 MiB

i.e. only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the
guest remains responsive.

Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko")
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Melbin K Mathew <redacted>
---
net/vmw_vsock/virtio_transport_common.c | 27 ++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)

Changes LGTM, but the patch seems corrupted.

$ git am ./v3_20251211_mlbnkm1_vsock_virtio_cap_tx_credit_to_local_buffer_size.mbx
Applying: vsock/virtio: cap TX credit to local buffer size
error: corrupt patch at line 29
Patch failed at 0001 vsock/virtio: cap TX credit to local buffer size

See also 
https://patchwork.kernel.org/project/netdevbpf/patch/20251211125104.375020-1-mlbnkm1@gmail.com/

Stefano