If you run KVM, libvirt or Proxmox, there is a critical kernel update waiting. CVE-2026-99999 is an IPv4 checksum flaw that lets an untrusted guest, or any local sender of crafted packets, corrupt host kernel memory: a crash, kernel memory disclosure or potentially arbitrary code on the host, per Red Hat. It tracks the flaw as an active-exploit case, reports no mitigation, and the action is a kernel update through your distribution.

Diagram: guest packet bytes and deferred checksum metadata crossing into the host Linux networking stack, over the guest to host trust boundary.
Figure 1: the guest-to-host boundary is crossed inside the host networking stack, not in KVM's VMX or MMU code. Image: pwn.ai research.

How a checksum becomes a write

Linux can defer a transport checksum: a packet carries metadata saying one is still to be completed, plus two values, where accumulation starts and where the result gets written. The kernel completes it in skb_checksum_help(), writing at start plus offset inside the transport header of a well-formed packet. Admit a malformed checksum_start and the deferred write lands outside that header: “If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief.” Those values are not passive; they “authorize a subsequent write into packet memory.”

They also shift as the packet moves, because link-layer headers are stripped on the way in; a header validated in one layout can be reinterpreted at write time.

The fix closes the path, not the class

The fix is upstream as 6785011f8b16, “ipv4: validate checksum_start before completing checksum”, backported through the stable trees; the CVE record links eight commits. It adds a completion-path check: “We really shouldn’t allow such packets in, but as a defence in depth measure, let’s also check before we complete the checksum.” Fuller validation at input “is forthcoming, but needs more work.”

What was demonstrated

The bug surfaced in Vercel’s $1M Sandbox challenge as its only Critical finding among “1,285 reports”. Host memory, “the machine your sandbox shares with other tenants,” “shows up in packets the guest sends over the internet,” demonstrated against Vercel’s production sandboxes. Sending two packets “crashed the host machine, shutting down every sandbox running on it”. The same flaw let the researcher “run commands with full administrator privileges on the host”, breaking out of “the sandbox’s isolation boundary”; both on “the researcher’s own KVM and Firecracker machines matching Vercel Sandbox configuration.”

Paulos Yibelo, who found it, puts it more bluntly: “the vulnerability wasn’t even in the hypervisor, it was in the Linux networking stack.” The oss-security note stays with what is published: the write-up “describes a host-memory disclosure and is phrased as a guest-to-host escape,” with a second part promised.

Who needs to act

Red Hat marks all its tracked product streams affected. It rates the flaw Important at 8.8 where CVE.org rates 9.3 Critical, a gap Red Hat attributes to the privileges-required metric. No record here names fixed kernel versions, so the advice is the same: update through your distribution.

Your guests are only as isolated as the host kernel’s packet handling. The patch closes the write an attacker needs; fuller input-side validation is still to come.

Sources: the pwn.ai write-up and Vercel’s findings; the NVD and Red Hat records; the fix commit with a stable backport; the oss-security note.