analyst@unixshadow:~$ explain pwnescape # a guest-to-host escape that is not a KVM bug
PwnEscape
One Checksum That Broke Out of the Guest
A guest VM hands the host a packet, plus a note saying “finish the checksum here.” The host trusts the note without checking it against the packet — and the note points at the packet’s own header. Everything after that is just consequences.
# the name is a trap — it is not a KVM bug
what: guest-to-host virtual machine escape, CVE-2026-99999, nicknamed PwnEscape
where: the host kernel’s IPv4 networking stack — not KVM, not the hypervisor
found by: Paulos Yibelo of PWNAI Research, during Vercel’s public sandbox security challenge
reported: privately to the kernel security contact and networking maintainers, 4 Sept 2026
fix: commit 6785011f8b16, “ipv4: validate checksum_start before completing checksum”, by Michael S. Tsirkin — merged to mainline 14 Oct 2026
rated: Critical by the kernel CVE team (CVSS 9.3); Important by Red Hat (8.8)
age: the vulnerable code dates to 2008 (virtio network header support for tun/tap, Linux 2.6.27) and 2010 (checksum offload for packet sockets) — roughly 18 years in the kernel
where: the host kernel’s IPv4 networking stack — not KVM, not the hypervisor
found by: Paulos Yibelo of PWNAI Research, during Vercel’s public sandbox security challenge
reported: privately to the kernel security contact and networking maintainers, 4 Sept 2026
fix: commit 6785011f8b16, “ipv4: validate checksum_start before completing checksum”, by Michael S. Tsirkin — merged to mainline 14 Oct 2026
rated: Critical by the kernel CVE team (CVSS 9.3); Important by Red Hat (8.8)
age: the vulnerable code dates to 2008 (virtio network header support for tun/tap, Linux 2.6.27) and 2010 (checksum offload for packet sockets) — roughly 18 years in the kernel
The name sends you to the wrong layer. If you go patching your guests, or auditing your KVM configuration, you have fixed nothing — the code being attacked does not run in your guest at all. It runs on the host, in the network stack, every time a guest packet passes through a virtio network device.
# the trust boundary — checksum offload, in plain terms
the deal: a guest does not have to compute a packet’s transport checksum itself. It sends the packet with the checksum still pending, and the host finishes the job. That is checksum offload, and it exists purely to save work.
the metadata: the packet carries three hints — the checksum is pending (
the catch: those hints are not descriptions. They are authorization to write to a location in packet memory, later. Anyone who controls them controls a future write. The host has to check that the write location sits after the IPv4 header. It did not.
the metadata: the packet carries three hints — the checksum is pending (
CHECKSUM_PARTIAL), where calculation starts (csum_start), and where the result goes (csum_offset). Final write location: csum_start + csum_offset.the catch: those hints are not descriptions. They are authorization to write to a location in packet memory, later. Anyone who controls them controls a future write. The host has to check that the write location sits after the IPv4 header. It did not.
This is a time-of-check, time-of-use shape: the kernel reads and acts on a header, and then a later write — authorized by metadata the guest supplied — changes the very thing that was already validated. Validation that can be rewritten after the fact is not validation.
# the rewrite, mocked up — illustrative values only, not a capture
guest (fictional): guest-alpha, address 203.0.113.45
host (fictional): hv-lab-01, receiving on a virtio network device
header as the kernel first reads it: IPv4, header length field (IHL) = 5, meaning a 20-byte header
crafted metadata: checksum-offload hints that point the checksum write back into the header itself
the write lands: on the IHL field. IHL changes from 5 to 15.
what the kernel does next: its IP fragmentation code now treats the header as 60 bytes instead of 20 — and proceeds on the basis of a packet layout that is no longer the one it validated
host (fictional): hv-lab-01, receiving on a virtio network device
header as the kernel first reads it: IPv4, header length field (IHL) = 5, meaning a 20-byte header
crafted metadata: checksum-offload hints that point the checksum write back into the header itself
the write lands: on the IHL field. IHL changes from 5 to 15.
what the kernel does next: its IP fragmentation code now treats the header as 60 bytes instead of 20 — and proceeds on the basis of a packet layout that is no longer the one it validated
One field, one write, and the kernel’s picture of the packet is wrong from then on. The researcher’s example is deliberately small — that is the point. The primitive is “write where the guest says,” and the rest is engineering.
Mock-up notice: every address, hostname and terminal value in this post is invented for illustration. Nothing here came from a real capture, a real host, or a real guest.
# three demonstrated outcomes — same primitive, three endings
1 — LEAK
effect: a repeatable leak of host kernel memory back to the attacker, for as long as the guest keeps sending packets
proven: demonstrated against Vercel’s production sandboxes; Vercel says no customer data was accessed
proven: demonstrated against Vercel’s production sandboxes; Vercel says no customer data was accessed
A leak is the quiet one, and the one that matters first: host memory contents handed to a tenant, on repeat, are the raw material for everything that follows.
2 — CRASH
effect: the host crashes — and takes down every VM running on it
On a shared host, a crash is not one tenant’s problem. It is an outage for every tenant on the machine, triggered by one of them.
3 — ROOT
effect: writes into host kernel memory, chained into running a program as root on the host
proven: on the researcher’s own KVM and Firecracker machines only — the full details are being held back for a follow-up write-up
proven: on the researcher’s own KVM and Firecracker machines only — the full details are being held back for a follow-up write-up
The root chain is the headline, but note the boundary: demonstrated in the lab, details withheld. What is public and proven is already bad enough without it.
Scope note: this post contains no exploit code, payloads, or reproduction steps. The trigger is a guest or local virtual-device path, not an internet receive path — but Red Hat’s assessment notes a local attacker can also trigger it, and the vulnerable code is in every AlmaLinux kernel whether or not the system runs VMs. No public exploit has been reported, and it was not CISA KEV-listed at last check.
# patched kernels — the version table is the whole story
AlmaLinux 8: kernel-4.18.0-553.177.1.el8_10 — AlmaLinux’s backport on top of the latest RHEL 8 kernel
AlmaLinux 9: kernel-5.14.0-687.59.1.el9_8 — carries Red Hat’s fix
AlmaLinux 10: kernel-6.12.0-211.67.1.el10_2 — carries Red Hat’s fix
in production since: 23 Oct 2026 — install the listed version, or higher
AlmaLinux Kitten 10: the fix rides along in the next regular kernel update; no separate build
AlmaLinux 9: kernel-5.14.0-687.59.1.el9_8 — carries Red Hat’s fix
AlmaLinux 10: kernel-6.12.0-211.67.1.el10_2 — carries Red Hat’s fix
in production since: 23 Oct 2026 — install the listed version, or higher
AlmaLinux Kitten 10: the fix rides along in the next regular kernel update; no separate build
AlmaLinux shipped ahead of upstream here: its testing kernels landed 16 Oct, before Red Hat’s fix existed, and the production kernels above replaced them a week later. If you enabled the testing repo to help test, disable it again once you are on a production kernel.
The trap: on AlmaLinux 9, kernel-5.14.0-687.58.1 is newer than the testing kernel — and does not contain the fix. Version-number arithmetic lies. Check the advisory, not the sort order.
# what to do — on a host, in order
1. Update the host kernel —
2. On a virtualization host, move the guests first — migrate or shut down every guest before the reboot, because the reboot interrupts all of them.
3. Confirm what is actually running —
4. Update every AlmaLinux system, not just virt hosts — the local trigger means a non-host box is in scope too.
5. If you rent VMs, this one is your provider’s — a tenant cannot patch the host. Ask when the host kernels were updated, and take the answer seriously.
dnf clean metadata && dnf upgrade, then reboot. The fix is the patched kernel; there is no workaround, from the researcher, upstream, or Red Hat.2. On a virtualization host, move the guests first — migrate or shut down every guest before the reboot, because the reboot interrupts all of them.
3. Confirm what is actually running —
uname -r or rpm -q kernel against the table above, after the reboot. Installed is not running.4. Update every AlmaLinux system, not just virt hosts — the local trigger means a non-host box is in scope too.
5. If you rent VMs, this one is your provider’s — a tenant cannot patch the host. Ask when the host kernels were updated, and take the answer seriously.
# the honest read
Patching your guest does nothing. Patching your hypervisor configuration does nothing. The only patch that counts lives on the host, in the kernel, and it needs a reboot — which on a virt host means scheduling around every tenant on the box. That is why this one is operationally annoying rather than just technically interesting.
And the deeper read is the age. This code sat in the kernel for roughly eighteen years — older than most of the VMs it now escapes from. Upstream calls the fix a defense-in-depth measure, and says more complete validation of incoming packets is still being worked on. Read that as: the demonstrated path is closed, the class of mistake is not yet fully retired. Patch now, and keep the kernel updates coming.
Sources: AlmaLinux advisory, 16 Oct 2026 (updated 23 Oct 2026, production kernels); CVE-2026-99999 record; PWNAI Research write-up; Vercel sandbox challenge summary. All addresses, hostnames and terminal values in this post are mock-ups.
unixshadow.com · VPS & hosting from the shadowsanalyst@unixshadow:~$