Re: [PATCH net v2] vhost/vsock: size receive SKBs from declared payload

[Will Deacon]

On Sun, Oct 04, 2026 at 04:34:19PM +0900, Daehyeon Ko wrote:
> vhost_vsock_alloc_skb() allocates an skb from the total guest descriptor
> length before reading hdr->len.  Descriptor capacity and declared payload
> length are independent, so a guest can supply a large descriptor with a
> zero or short payload.
> 
> On Linux v7.2, 455 zero-payload packets with 64 KiB descriptors retained
> 30,255,680 bytes on a 256 KiB receive buffer while rx_bytes and buf_used
> stayed zero.  A full-payload control retained 265,984 bytes.  The existing
> SKB_TRUESIZE(0) budget caps skb count but does not account for the
> descriptor-sized allocation.

Are you saying that we leak the descriptor memory or that we don't account
for it properly or something else? I'm trying to understand why the
zero-payload part is important.

> Repeating this across connections can exhaust host kernel memory.
> 
> Trimming after allocation is insufficient.  Linear skbs retain their full
> head, while a nonlinear payload exceeding head tailroom can retain its
> first page fragment.

Seems like a weird paragraph to include here... that's commentary on why
you did a v2, no?

> Copy the header into a stack object, validate hdr->len before allocating,
> and size the skb from the declared payload plus the header.  This keeps the
> allocation proportional to receive accounting for both linear and
> nonlinear skbs.
> 
> Use payload_len > len - sizeof(hdr) for validation.  This avoids addition
> overflow on 32-bit hosts and ensures payload_len fits the subsequent
> int-length copy path.
> 
> Fixes: ab9aa2f3afc2 ("vhost/vsock: Allocate nonlinear SKBs for handling large receive buffers")

Are you sure about this Fixes tag? The linear allocation before that
patch doesn't look much different when considering the report above (which
is a little hard to follow given that it's the usual LLM-style of prose).

Will