Linux kernel virtio-net: loose length check in receive_big() lets a malicious backend write past the frag array

Impact

receive_big() bounds the device-announced packet length at (big_packets_num_skbfrags + 1) * PAGE_SIZE, but add_recvbuf_big() actually advertises about 20 bytes less for the common 12-byte header case, because the first scatter entry starts past the padded vnet header. A backend that announces a length in that gap makes page_to_skb() walk one fragment past the page chain and store a NULL page into skb_shinfo()->frags[MAX_SKB_FRAGS] - an out-of-bounds write past a fixed-size array in the guest kernel, plus a NULL fragment handed further up the receive path. The exposure is guest-side and the attacker is whoever controls the virtio-net backend, so for a GPU cloud this matters where the backend is not fully trusted by the guest: confidential VMs, vhost-user or offloaded/DPU-hosted datapaths, and nested setups. On a plain KVM host that already owns its guests it adds little, since the host is inside the trust boundary already.

Who can reach it

Whoever controls the virtio-net backend serving a guest - a hypervisor-side vhost/vhost-user process, a DPU or SmartNIC datapath, or an emulated device - can trigger it by announcing a crafted receive length. No guest credentials are needed; the guest only has to be running the virtio-net driver with big-packet receive buffers.

What to do

Update the guest kernel to a build carrying the fix that bounds len by what add_recvbuf_big() advertised, and reboot the VM; the fix landed across several stable branches (commits linked below). There is no runtime toggle - big-packet mode is chosen by feature negotiation - so the practical path is to roll patched guest images and restart tenant VMs, which for a GPU tenant means draining the workload first. Host kernel and GPU driver stack are unaffected.

References

Related entries

• Linux kernel io_uring: per-task restrictions are freed across exec, so post-exec rings are unrestrictedCVE-2026-80713 · Linux kernel io_uring (per-task restrictions dropped on exec)High
• Intel Data Center GPU driver for VMware ESXi (out-of-bounds read): Out-of-bounds read in the ESXi GPU driver exposingCVE-2026-20751 · Intel Data Center GPU driver for VMware ESXi (out-of-bounds read)High
• Intel Data Center GPU driver for VMware ESXi (out-of-bounds write): Out-of-bounds write in the ESXi GPU driver causingCVE-2026-20879 · Intel Data Center GPU driver for VMware ESXi (out-of-bounds write)High
• Xen PCI passthrough on Intel VT-d chipsets without interrupt remapping: The founding GPU-passthrough escape. A guestCVE-2011-1898 · Xen PCI passthrough on Intel VT-d chipsets without interrupt remappingHigh
• Xen libxl (xenlight) PCI passthrough device setup: The toolstack hands a bus-mastering-capable PCI device to an HVMCVE-2013-4329 · Xen libxl (xenlight) PCI passthrough device setupHigh
• Xen Intel VT-d IOMMU page-table handling for PCI passthrough: An inverted boolean means Xen clears a present IOMMUCVE-2013-6375 · Xen Intel VT-d IOMMU page-table handling for PCI passthroughHigh