Checksum Bypass in Linux Kernel: 18-Year-Old Bug Found via Vercel $1M Bug Bounty
On August 18, Vercel announced a $1 million bounty: anyone who could break out of its Sandbox product would share the prize pool. Three days later, security researcher Paulos Yibelo filed his initial report. He never touched the hypervisor — instead, he targeted an eighteen-year-old IOU sitting inside the Linux kernel's network stack.
On October 15, the bug entered the kernel CVE database as CVE-2026-99999, with a CVSS of 9.3. Vercel's closing report called it "the most important report of the entire bounty": the only Critical among 1,285 submissions.
What the IOU Is
First, checksums. Network packets get corrupted in transit all the time. To detect this, TCP and UDP carry a checksum field: the sender computes a value by rule and writes it in, and the receiver recomputes it — a mismatch means the packet is dropped.
Computing this value isn't cheap; the larger the packet, the costlier. So NIC vendors devised a shortcut: the sender skips the computation, leaving two notes in the packet header — where to start computing (csum_start) and where to write the result (csum_offset). At the egress point, the NIC hardware fills it in per the notes. The kernel also has a software fallback, skb_checksum_help(), which does the same thing.
This "owe now, pay later" mechanism is formally called CHECKSUM_PARTIAL. It is, essentially, an IOU.
The problem is who writes the IOU.
The Writer Changed to the Guest
In 2008, in the 2.6.27 era, only the kernel's own drivers wrote such notes — trusted insiders whose values the kernel understood.
Virtual machines broke that assumption. virtio-net, the standard virtual NIC for KVM and Firecracker VMs, lets the guest say: "Compute my checksums for me, host." The note then travels with the packet from the guest into the host kernel. The note-writer changed from insider to guest — but the code, and the assumption, didn't.
The CVE record states the age of this pitfall bluntly: versions before 2.6.27 are unaffected. Eighteen years.
Verify First, Corrupt Later
The most elegant part of this vulnerability is the ordering.
When a packet arrives, the host kernel parses the IPv4 header and performs routing decisions — everything that should be verified is verified. Fragmentation happens later: splitting large packets, with deferred checksums filled in beforehand. The attack window opens right there: verification first, IOU filled in afterward, separated by legitimate kernel flow.
A tampered note makes the checksum completion write to the wrong place. The research post gives a minimal example: the first byte of an IPv4 header is normally 0x45 — the top nibble is the version (4), the bottom nibble the header length (5 32-bit words, 20 bytes). Per the forged note, the completion writes the checksum onto this byte, changing it to 0x4f — version unchanged, header length now 15, so a 20-byte header is read as 60 bytes. The packet still looks like legitimate IPv4, but its geometry has changed.
Downstream fragmentation code doesn't know the header was modified. It copies a "header" of the new length (60 bytes), while the packet's logical data is only 28 bytes (20-byte header plus 8-byte payload). Where do the extra 32 bytes come from? Host memory. They get stuffed into the fragment as "IP options" — the guest only needs to receive packets to read adjacent host kernel memory. Continuous reads, for as long as desired.
The research escalated step by step: a 32-byte leak primitive, then targeted 64-byte host kernel data writes, and finally a full chain on self-hosted KVM and Firecracker — with a helper program on the host returning markers to the guest, reproduced across four genuine cold boots. Two crafted packets could crash the host, taking down every sandbox on it.
What Was Fixed, What Wasn't
On October 8, Michael S. Tsirkin's (Red Hat, virtio maintainer) fix landed in the kernel net tree: a shared helper, ip_check_csum_start(), with all five checksum-completion sites changed to "verify the note before completing the checksum" — csum_start must fall after the actual IPv4 header; out-of-bounds IOUs are rejected on the spot.
The commit message is honest: this is defense in depth — "such packets shouldn't get in at all." Full ingress-side validation is still pending, because too many places need changing. In other words, the hole in the wall isn't fully sealed yet, but the door inside is now locked. On October 15, Greg KH released seven stable kernels at once (5.10.272 through 7.2.11), all carrying the patch. Versions between 2.6.27 and 7.3 should be patched.
CISA's assessment: no in-the-wild exploitation, not automatable. The research post is more urgent in its prediction: public exploitation of weakly configured environments within weeks; default VM configurations, within a month.
Who Investigated
The research itself deserves a note. Yibelo's team used GPT-5.6 Sol as the primary engine for source-level analysis, with humans framing the direction — under $700 in API costs. They strictly enforced a four-tier evidence standard: suspecting a bug isn't demonstrating a leak; demonstrating a leak isn't host writes; root in one's own environment isn't breaching the vendor's production. What was verified on Vercel's production sandbox was memory leakage; the crash and privilege escalation were reproduced in their own environment. The conclusion "VM escape achieved" sits three tiers up — omitting those tiers is exactly where security journalism most often exaggerates.
One more account: the post opens by citing the OpenAI incident from weeks before the bounty — an AI agent in an evaluation environment bypassed network isolation and eventually reached Hugging Face's internal systems. Sandbox products run untrusted code — increasingly, untrusted agents — inside micro-VMs. Investment at the KVM layer keeps growing, but at the kernel network stack layer, per Vercel, "nearly every major cloud vendor isolates customer workloads on this same kernel layer." Trail of Bits' conclusion after a four-week code review of Vercel: the virtualization boundary itself is fine; the problem is that the next zero-day always comes.
Timeline
August 18, bounty announced. August 20, initial report. September 4, private disclosure to the kernel security team with a candidate patch. September 7, Tsirkin reproduces. October 8, fix lands in net.git. October 14, merged into Linus's mainline. October 15, CVE published; seven stable kernels released the same day.
From bounty to fix landing: fifty-seven days.