On 12/17/25 7:12 PM, Melbin K Mathew wrote:
> The virtio vsock transport derives its TX credit directly from
> peer_buf_alloc, which is set from the remote endpoint's
> SO_VM_SOCKETS_BUFFER_SIZE value.
>
> On the host side this means that the amount of data we are willing to
> queue for a connection is scaled by a guest-chosen buffer size, rather
> than the host's own vsock configuration. A malicious guest can advertise
> a large buffer and read slowly, causing the host to allocate a
> correspondingly large amount of sk_buff memory.
>
> Introduce a small helper, virtio_transport_tx_buf_alloc(), that
> returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume
> peer_buf_alloc:
>
> - virtio_transport_get_credit()
> - virtio_transport_has_space()
> - virtio_transport_seqpacket_enqueue()
>
> This ensures the effective TX window is bounded by both the peer's
> advertised buffer and our own buf_alloc (already clamped to
> buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote guest
> cannot force the host to queue more data than allowed by the host's own
> vsock settings.
>
> 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 patch applied:
>
> Before:
> MemFree: ~61.6 GiB
> Slab: ~142 MiB
> SUnreclaim: ~117 MiB
>
> After 32 high-credit connections:
> MemFree: ~61.5 GiB
> Slab: ~178 MiB
> SUnreclaim: ~152 MiB
>
> Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest
> remains responsive.
>
> Compatibility with non-virtio transports:
>
> - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per
> socket based on the local vsk->buffer_* values; the remote side
> cannot 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 cannot 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.
>
> This change is limited to virtio_transport_common.c and thus affects
> virtio and loopback, bringing them in line with the "remote window
> intersected with local policy" behaviour that VMCI and Hyper-V already
> effectively have.
>
> Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko")
> Suggested-by: Stefano Garzarella <[email protected]>
> Signed-off-by: Melbin K Mathew <[email protected]>
Does not apply cleanly to net. On top of Stefano requests, please rebase.
Thanks,
Paolo
