Zapscape: A Critical KVM Guest-to-Host Escape in the Linux Kernel Shadow MMU
A critical use-after-free in KVM's shadow MMU code, disclosed August 6 as CVE-2026-64561, allows a privileged guest VM to escape isolation and run code as root on the host.
On August 6, a security researcher named Hyunwoo Kim published full details of a critical Linux kernel vulnerability that had been silently patched three weeks earlier. The bug, assigned CVE-2026-64561 and given the name Zapscape, is a use-after-free in KVM’s x86 shadow MMU emulation code — specifically in the recursive “zap” path that the kernel uses to tear down page table mappings when a virtual machine’s memory is being reconfigured. The Hacker News reported that the flaw allows an attacker with kernel privileges inside a privileged L1 guest to escape KVM isolation entirely and execute code as root on the host.
The shadow MMU is the mechanism KVM relies on to manage how a guest virtual machine sees physical memory without handing the guest direct control over the host’s actual page tables. Every time the guest modifies a page table entry, the shadow MMU intercepts and translates it into something the host’s real MMU can enforce. The zap path is the cleanup routine — when a page table entry needs to be invalidated, the kernel walks the shadow structures and unmaps them. The recursive nature of that walk is where the bug lives: a carefully crafted sequence of guest-initiated page table changes can trigger a use-after-free, where memory the kernel is relying on during the walk has already been freed by an earlier step in the same sequence.
What makes Zapscape especially consequential is the window of exposure. Phoronix noted that every Linux kernel from mid-2020 through the July 21 patch is vulnerable — more than six years of production kernels shipping with KVM enabled by default on virtually every enterprise and cloud distribution. The fix landed in a routine merge on July 21, but it was a quiet commit without a security advisory. The public proof-of-concept that Kim released on August 6 is what turned a three-week-old patch into an active concern, because anyone running an unpatched kernel with KVM and a world-writable /dev/kvm device is now facing a reliably exploitable guest-to-host escape.
The exploit chain is straightforward in concept: an attacker who has already obtained kernel-level code execution inside a guest VM — a realistic assumption in environments where multiple tenants share hypervisor hardware, or where a separate vulnerability has already elevated an unprivileged user — triggers the use-after-free in the recursive zap path. The freed memory is then reclaimed and shaped so that when the kernel dereferences it during the MMU walk, execution redirects to attacker-controlled data. Because the zap path runs in host kernel context, the attacker lands at root on the bare metal, outside any VM boundary. There is no secondary privilege escalation required; the escape itself delivers full host compromise.
The six-year gap between introduction and disclosure is not unusual for KVM subsystem bugs — the shadow MMU codepath is deeply intertwined with x86 memory management and has been refactored incrementally across dozens of kernel releases — but it does mean that every cloud provider, every enterprise virtualization host, and every developer running local VMs with KVM over that period was carrying the exposure. Kernel live-patching infrastructure can deliver the fix without reboots for distributions that support it, but for anyone not running livepatch or equivalent, the only safe path is a full kernel upgrade and a reboot of every KVM host, now.