Linux kernel virtio-net: unchecked received length in xdp_linearize_page allows an out-of-bounds read

Impact

When virtio-net linearises a multi-buffer packet for XDP, it reads follow-on buffers off the ring without comparing the reported received length against the size actually allocated, so a length larger than the buffer produces an out-of-bounds read inside the guest kernel. The length comes from the virtio device side, which means the untrusted party here is the hypervisor-side backend or whatever can feed the virtqueue - the classic guest-hardening concern for VM-based GPU tenancy, where a tenant VM's kernel must not trust its paravirtual NIC. Impact is kernel memory disclosure into packet processing and guest crashes; it requires XDP to be attached to the virtio-net interface, which a stock server without an XDP program does not do.

Who can reach it

Reached from the virtio device side: a malicious or compromised virtio-net backend, or a device emulation layer, supplies an oversized buffer length. Requires an XDP program attached to the virtio-net interface in the guest. No guest authentication is involved.

What to do

Update guest kernels to a stable release carrying the added length check (five backports linked) and reboot the VMs. Rollout is a guest-side reboot per instance rather than a host maintenance window. Detaching XDP programs from virtio-net interfaces removes the vulnerable path in the meantime, at the cost of whatever that XDP program does.

References

Related entries

• Linux i915 GPU kernel driver (GT timeline / VMA allocation): A timeline is left held when VMA allocation fails, soCVE-2025-38389 · Linux i915 GPU kernel driver (GT timeline / VMA allocation)High
• Linux kernel SMC (struct smc_sock type confusion with inet_sock): Struct smc_sock does not embed struct inet_sock asCVE-2025-38475 · Linux kernel SMC (struct smc_sock type confusion with inet_sock)High
• Linux kernel (net/xfrm): The guard that forbids changing a collect_md xfrm interface never fired, so a changelink putsCVE-2025-38500 · Linux kernel (net/xfrm)High
• Linux kernel (drivers/iommu/intel): VT-d tore the device off the I/O page-fault queue before the hardware had stoppedCVE-2025-38594 · Linux kernel (drivers/iommu/intel)High
• Linux kernel (net/tls): KTLS assumes it owns the TCP receive queue. When another reader drains bytes first, the oldCVE-2025-38616 · Linux kernel (net/tls)High
• Linux kernel (net/xfrm): If the task is preempted onto another CPU during SA lookup, a hit in the per-CPU state cacheCVE-2025-38675 · Linux kernel (net/xfrm)High