QEMU checksum bug can read past packet buffers

A crafted packet can push QEMU's shared network checksum code past the end of a packet buffer, a flaw tracked as CVE-2026-127233. Peter Maydell has sent a fix.

The code computes TCP and UDP checksums for several virtual network devices. A packet whose IP header length is larger than the total length it claims can drive an internal length negative. That value then survives later range checks, because it is compared as an unsigned quantity, and QEMU checksums roughly 64KB of memory beyond the buffer. The usual result is a crash. If the read does not fault, some callers also store the two-byte checksum out of bounds.

Maydell wrote that the code is used by at least the Xen NIC, virtio-net and the COLO filter rewriter, all inside QEMU's virtualization security boundary, as well as other devices treated as out of scope. He said it is not clear the bug is exploitable on every one of those paths. He judged that an out-of-bounds write is probably practical only for the COLO rewriter. Elsewhere the realistic outcome is a guest crash, or a theoretical leak to the guest of a two-byte checksum over 64KB of host RAM.

A second change is not a security fix. The checksum code ignored IP options when locating the TCP or UDP header, so it could write the checksum at the wrong offset.

Akihiko Odaki said a new assertion in the fix, that the buffer length is positive, can itself abort QEMU. The eTSEC Ethernet device accumulates descriptor lengths without a frame-size cap and can hand a value larger than 2GB to a signed length parameter. He suggested making that length an unsigned type large enough to hold it, which would also remove the need for the assertion.