Database/Kernel, userspace & hypervisor
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 sockmap: 32-bit wrap in bpf_msg_pop_data bounds check runs the pop loop off the scatterlistCVE-2026-74256 · Linux kernel bpf sockmap (bpf_msg_pop_data bounds check overflow)High
- 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
- Linux kernel qla2xxx: MSI-X vector count truncates to zero and the driver dereferences ZERO_SIZE_PTRCVE-2026-89856 · Linux kernel qla2xxx (MSI-X derived queue counts)High
- Linux kernel arm64 ptrace: tracer-modified x0 escapes seccomp re-evaluationCVE-2026-90347 · Linux kernel arm64 ptrace (orig_x0 vs x0 sync on syscall entry)High
- Linux kernel virtio-fs: double free of fs->vqs and fs->mq_map when queue setup fails during probeCVE-2026-93827 · Linux kernel virtio-fs (double free on virtio_fs_setup_vqs() probe failure)High
- Linux kernel io_uring: IPv6 connect filters bypassed with a 24-byte sockaddr_in6CVE-2026-99042 · Linux kernel io_uring/net (connect BPF filter field population)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.