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
