CVE-2026-99999: the IPv4 checksum bug that can escape a VM

Debian security tracker lists CVE-2026-99999 as a missing IPv4 checksum check in the Linux kernel, exploitable from a guest to the KVM host. Fixed in 6.1.190-1 (bookworm) and 6.12.113-1 (trixie).

Debian security tracker entry for CVE-2026-99999, listing the fixed versions for bookworm and trixie (source: security-tracker.debian.org, captured 2026-10-19)

Figure: Debian security tracker entry for CVE-2026-99999, listing fixed versions for bookworm and trixie (source: security-tracker.debian.org, captured 2026-10-19)

The entry on Debian’s tracker is suspiciously short: one sentence, one upstream commit, two version tables. What it points to is not small — it is the entry point of the guest-to-host KVM escape chain known as PwnEscape, and both bookworm and trixie are affected.

The bug: an offset computed in the wrong coordinate system

PWNAI’s PwnEscape research page, titled Guest-to-Host KVM Escape (source: pwn.ai/blog/pwnescape, captured 2026-10-19)

Figure: PWNAI’s PwnEscape research page, titled Guest-to-Host KVM Escape (source: pwn.ai/blog/pwnescape, captured 2026-10-19)

The upstream commit is ipv4: validate checksum_start before completing checksum (6785011f8b16, landed in 7.3-rc7). The problem is that the checksum start offset is taken from one layer and then applied to a buffer measured in another layer. When the two disagree, the kernel reads or writes outside the intended region. That is enough to turn a packet-level primitive into memory corruption inside the host kernel.

Why Debian is involved

Debian ships the same kernel code, so the fix has to be backported. The tracker lists:

Release Fixed version Advisory
bookworm 6.1.190-1 DLA-4841-1
trixie 6.12.113-1 DSA-6568-1
sid 7.2.11-1 —

The bookworm fix arrives through a point release (DLA), trixie through a regular DSA. If you pin your kernel, pin the patched one.

Fixing it

apt update && apt full-upgrade is the short version, but a reboot is required for a kernel change. Check the running kernel afterwards with uname -r; a package upgrade without a reboot leaves the vulnerable kernel running.

One naming clarification

PwnEscape and CVE-2026-99999 are related but not the same thing. PwnEscape is the research and the exploit chain; the CVE covers the specific checksum validation flaw. Do not search for a “PwnEscape CVE” — search the commit.

Why the two coordinates drift apart

The offset is computed while walking the IPv4 header, then reused when checksumming a buffer that may include encapsulated data. When the packet carries another protocol layer (for example, a tunnelled frame), the offset refers to a different origin than the buffer. That mismatch is the bug.

Timeline

The upstream fix landed in 7.3-rc7. Debian backported it within days, publishing DLA-4841-1 and DSA-6568-1. The public write-up from PWNAI followed. If you are on an LTS kernel branch, the backport is what matters.

Check whether you are patched

uname -r
dpkg -l linux-image-$(uname -r) | tail -1
apt-cache policy linux-image-amd64

Compare the installed version with the table above. If you are below it, upgrade and reboot.

Extra steps for agent sandboxes

If you run untrusted code inside microVMs, the host kernel is the boundary. This CVE is a reminder that the boundary is code, not a promise. Patch the host, keep the guest kernel minimal, and do not assume that a microVM makes the host kernel unreachable.

Containers, cloud hosts, physical machines

Containers share the host kernel, so a container escape here is really a host-kernel escape. Cloud instances need the provider’s patched image or your own kernel. Physical machines need the same reboot discipline.

My take

The tracker entry looks boring, which is exactly why it is dangerous. A one-line description hides a guest-to-host primitive. Patch, reboot, verify — and if you run sandboxes, treat the host kernel as part of the sandbox.

← Back to all posts

Comments

…