Linux's October 2026 PwnEscape Bug Explained: How a Checksum Hint Leaks Memory

The host can follow that hint later, overwrite data it has already checked, and leak its own memory. That is the PwnEscape KVM escape, a Linux kernel bug tracked as CVE-2026-99999. A CVE is the public ID for a known security flaw.

Picture a cloakroom form with a box that says how many pages it has. Your slip tells the attendant which box to write your ticket total in later. The attendant checks the form, files it, and later writes the total exactly where your slip said, over the page-count box. Where the picture breaks: the attendant here is the host's own code, and the slip is network metadata, not paper.

Consider a common setup. A platform team runs untrusted customer code and AI-agent sandboxes inside microVMs, tiny fast virtual machines, on its own fleet of KVM host machines. The setup is made up, but the bug is real.

The team has two questions about the advisory. Are these hosts exposed, and what should they do today? This guide works through both.

You need seven ideas, each with an everyday picture.

• Virtual machine (VM): a pretend computer inside a real one. The real machine is the host.
• KVM: the Linux kernel's built-in hypervisor, the part that runs VMs. QEMU and Firecracker are helper programs that drive it.
• MicroVM: a stripped-down, fast-booting VM used to isolate one small workload, such as one customer's code.
• Guest-to-host escape: code inside a VM reaches out and affects the host, breaking the wall between tenants.
• virtio-net: the standard fast network device a guest uses to hand packets to the host through shared memory.
• Checksum offload: the guest asks the host to finish a packet's checksum, a small error-check number, later.
• IPv4 header: the label at the front of a packet. One field says how long the header is.

It is a guest-to-host KVM escape in the Linux host's network code. A guest VM sends a packet with a checksum hint pointing at where the host should write the checksum later. If that spot overlaps the IPv4 header the host already checked, the later write changes the header.

The vulnerable part is the host networking stack, not any one cloud provider's setup. pwn.ai researcher Paulos Yibelo reported it on day three of Vercel's $1 million Sandbox challenge. The pwn.ai write-up calls the bug class deferred-metadata trust inversion. It says a large model did much of the source-code analysis, with humans directing the work.

The host reads the guest's header once and trusts its own record of it. Later, when it completes the checksum, it writes where the guest's hint points, without re-checking. That host write, aimed by the guest, makes the header claim to be longer than it really is.

The guest writes packets into memory it shares with the host, then rings a doorbell. The host kernel reads them and sends them on. A small header can ask the host to finish the checksum.

The host checks the IPv4 header first, then does other work, then completes the checksum last. The gap between the check and the write is the whole problem. Engineers call this time-of-check versus time-of-use. Here the guest changes nothing after the check; the host's own later write does.

The guest's virtio-net header carries two numbers, csum_start and csum_offset. Together they tell the host where to write the checksum. The guest aims that spot at the IPv4 header's first byte, which holds the header length.

That length field, called IHL, counts 4-byte words. The byte 0x45 means IPv4 with five words, so 20 bytes. The host's checksum write turns it into 0x4f, fifteen words, so 60 bytes.

Next comes fragmentation, which splits a packet too big for the link into smaller pieces, each with its own copy of the header. It copies a 60-byte header, but the packet's first block of data held only 28 bytes: a 20-byte header plus 8 bytes of payload. The other 32 bytes come from host memory outside the packet and can travel out to the network.

# Toy model of PwnEscape: a checked header, then a later write
header = bytearray(b"\x45" + b"\x00" * 19)     # 20-byte IPv4 header; length lives in byte 0
checked_len = (header[0] & 0x0F) * 4           # host reads the header length once: 20 bytes

def complete_checksum(position, guard):
    if guard and position < checked_len:       # the fix: refuse a write inside the header
        return "refused"
    header[position] = 0x4F                     # deferred write lands where the guest chose
    return (header[0] & 0x0F) * 4              # length the host now believes the header has

print(complete_checksum(position=0, guard=False))  # bug: header now claims 60 bytes
header[0] = 0x45                               # reset for the second run
print(complete_checksum(position=0, guard=True))   # patched: refused

No takeover of a production host was shown. Vercel says the memory leak was demonstrated against its production sandboxes. Crash and code execution were shown on the researcher's own KVM and Firecracker machines. Vercel says no reports showed anyone accessing customer data in Vercel Sandbox.

A memory leak is still serious on a sandbox host. Leaked host memory can hold secrets, keys or another tenant's data. So treat PwnEscape as a real escape of information, even where code execution was not proven in production.

Any Linux host that lets a less-trusted guest send packets through virtio-net and out the IPv4 path. That covers VM hosts, microVM sandboxes and AI-agent sandboxes on your own KVM machines. The attacker sits inside the guest.

The flaw sits in code present since Linux 2.6.27. The CVE record marks every kernel from 2.6.27 up to the fixed versions as affected. The reported leak used the IPv4 fragmentation path; the fix also guards other IPv4 checksum-completion paths.

The write-up says setups without a VM were also considered: TUN devices and AF_PACKET sockets. TUN is a virtual network card a program drives, and AF_PACKET lets a program send raw packets. The fix commit traces the bug to the offload support added for both.

The common setup above fits exactly this shape: untrusted guests on KVM hosts, all sending network traffic. So the team treats every host as exposed until each one runs a fixed kernel.

PwnEscape scores from 8.8 to 9.3 on CVSS, a 0 to 10 severity scale, and Ubuntu sets its priority at Medium. The two CVSS scores differ only on the privileges an attacker needs first.

A changed scope means the harm reaches beyond the attacked part, such as a guest reaching its host. Both scores count a changed scope and treat the attack as local, from inside the machine or guest. The kernel team assumes no privileges are needed, giving 9.3. Red Hat assumes the attacker already holds low privileges, such as an ordinary account, giving a preliminary 8.8.

The sources disagree on exploitation. Red Hat's page says it tracks the flaw as a KEV active-exploit case. KEV is CISA's Known Exploited Vulnerabilities catalogue. That catalogue, last updated 16 October 2026, did not list it when we checked on 19 October 2026. Recheck both pages before you set your urgency.

Install a kernel that contains the fix, then reboot into it. The first fixed stable versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 and 7.2.11. The mainline fix is in 7.3-rc7.

The fix adds a small guard, ip_check_csum_start(), before the host completes the checksum. It returns an error when csum_start falls before the network header start plus the IPv4 header length. So the checksum write must land at or past the end of the parsed header.

Five places call the guard: IPv4 fragmentation, bridge connection tracking, the netfilter packet queue, the iptables CHECKSUM target and IPsec output. Netfilter and iptables are Linux's firewall tools, and IPsec encrypts IP traffic. The patch, by Michael S. Tsirkin, is defence in depth: an extra check, since such packets should never get in at all. Fuller input checks are still to come as of 19 October 2026.

Distributions backport the fix, copying it into their older kernel lines under their own version numbers. Debian fixed it in its security updates: 6.1.190-1 for bookworm and 6.12.113-1 for trixie. Confirm the fixed package on your vendor's CVE page.

Not every vendor has a fix yet. As of 19 October 2026, Ubuntu lists its main kernel packages as Needs evaluation, with no fixed package. Red Hat marks all tracked product streams affected, with fixes in progress. Until your fix ships, move untrusted guests to hosts already on a fixed kernel, and keep checking.

1. 1

   List every KVM host

   Include VM hosts, microVM sandboxes and AI-agent sandbox hosts. Miss one and that host stays open.

2. 2

   Find your fixed package

   Open your distribution's CVE-2026-99999 page and note the fixed kernel for your release. If none exists yet, move untrusted guests to fixed hosts and keep checking.

3. 3

   Patch the busiest hosts first

   Start with hosts running the most untrusted guests, since they face hostile code now.

4. 4

   Reboot into the new kernel

   The package does nothing until the host runs it. Move running guests to another host first.

5. 5

   Verify after reboot

   Confirm the running kernel version on every host, and recheck it after any rollback.

First run uname -r on each host to see the running kernel. On a fixed upstream 6.12 kernel you should see 6.12.113 or later. Some distribution strings, such as 6.1.0-28-amd64, hide the upstream number, so check the package version instead.

The script below prints the running kernel and whether it carries the upstream fix. A backported vendor kernel may show False here, so read your vendor's page too. It prints None for a string it cannot read.

import platform
import re

FIRST_FIXED = {(5, 10): 272, (5, 15): 223, (6, 1): 190, (6, 6): 159,
               (6, 12): 113, (6, 18): 57, (7, 2): 11}

def is_fixed(release):
    m = re.match(r"(\d+)\.(\d+)(?:\.(\d+))?", release)
    if not m:
        return None                              # unknown format: check by hand
    major, minor = int(m[1]), int(m[2])
    patch = int(m[3] or 0)
    rc = re.search(r"rc(\d+)", release)          # -rc6, 0.rc6, 070300rc6
    if (major, minor) == (7, 3) and rc:
        return int(rc[1]) >= 7                   # mainline fix landed in 7.3-rc7
    if (major, minor) >= (7, 3):
        return True
    return patch >= FIRST_FIXED.get((major, minor), 10**6)

print(platform.release(), "upstream fix:", is_fixed(platform.release()))

Tell it as a story about trusting input across a boundary, and about timing.

1. 1

   Name the boundary

   A guest is less trusted than the host. The host must not act on a guest's hint without checking it.

2. 2

   Give the mechanism

   The host checked a header, then wrote a checksum where the guest pointed, overwriting the header.

3. 3

   Name the bug class

   Time-of-check versus time-of-use: the host's own deferred write changed the header after its check.

4. 4

   Size the risk honestly

   Proven production harm was a host memory leak. Code execution was shown only in the lab.

5. 5

   Give the design lesson

   Re-check guest data at the moment you act on deferred work. The host kernel is the real wall.