Skip to main content
CybersecurityVulnerability Management

Linux KVM Flaw Lets Guest VMs Escape to Host on Intel, AMD Systems

Server setup in a clean lab environment shows signs of vulnerability.

Roughly 16 years after the code was introduced, a use-after-free bug in Linux's KVM shadow MMU can be triggered from inside a guest to corrupt the host kernel's shadow-page state, researchers disclosed. Tracked as CVE-2026-53359 and nicknamed "Januscape," the flaw allows a guest to panic its host and, according to the researcher, can be turned into full host code execution by an unreleased exploit.

Januscape (CVE-2026-53359): a 16-year-old shadow MMU use-after-free

Security researcher Hyunwoo Kim (@v4bel) reported the bug, which lives in KVM's shared shadow MMU code used on both Intel and AMD x86 systems. The vulnerable logic dates to commit 2032a93d66fa in August 2010 and was corrected by commit 81ccda30b4e8 merged into mainline on June 19, 2026. Kim described Januscape as, to the best of public knowledge, the first guest-to-host exploit triggerable on both Intel and AMD.

How the shadow-page mix-up lets guests crash — and sometimes escape

KVM maintains private page tables that mirror a virtual machine's memory. When KVM needs a tracking page, it looks for one to reuse. The bug matched pages by memory address (the GFN) alone and ignored the page's role. Two different shadow-page types can share the same address but serve different purposes; reusing the wrong type corrupts KVM's internal records.

Most of the time the kernel notices the inconsistent records and intentionally panics to avoid further damage — the publicly released proof-of-concept demonstrates precisely this host panic, taking every VM on the physical host down. The more dangerous, rarer path occurs when a freed tracking page is handed out again before cleanup completes: the subsequent cleanup writes a value into memory the kernel no longer owns. An attacker controls where that write lands, and Kim says that withheld exploit code escalates that foothold into running code as root on the host. The final exploitation steps differ between Intel and AMD.

Who is affected and the attack prerequisites

The practical attack surface is any x86 KVM host that allows untrusted guests with nested virtualization enabled. Two guest-side conditions are required: root privilege inside the VM and nested virtualization exposed by the host. Even on hosts that default to hardware EPT or NPT, nested virtualization forces KVM back through the legacy shadow MMU where this bug resides. The exploit requires no cooperation from QEMU or other userspace VMMs — it is purely in-kernel KVM code.

Kim also noted a secondary risk on distributions where /dev/kvm is world-writable (0666): the same bug could serve as a local privilege escalation to root. ARM64 hosts are not affected by Januscape; a separate KVM/arm64 issue, ITScape (CVE-2026-46316), is an independent matter.

Patch details, timeline, and short-term mitigations

The fix is a one-line change to kvm_mmu_get_child_sp(): reuse now requires both a matching frame number (gfn) and a matching role.word, preventing shadow pages of different types from being swapped. KVM maintainer Paolo Bonzini authored the patch. Fixed stable kernels shipped on July 4, 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260. The National Vulnerability Database had not assigned a CVSS score at the time of disclosure; the public advisory warns operators not to wait for that score.

If you cannot apply a patched kernel immediately, disabling nested virtualization removes the attack path for untrusted guests: set kvm_intel.nested=0 or kvm_amd.nested=0. The public proof-of-concept requires only a loadable kernel module in the guest and seconds to minutes of racing to reliably produce a host panic, so exposed x86 KVM hosts with nested virtualization enabled should be treated as high-priority patch targets.

Hyunwoo Kim, kvmCTF, and a cluster of KVM disclosures

Januscape is the third kernel exploit Kim disclosed in about two months. In May 2026 he published Dirty Frag (CVE-2026-43284 / CVE-2026-43500), a page-cache write chain delivering deterministic root on many distributions. In June he disclosed ITScape (CVE-2026-46316), the first public guest-to-host escape on KVM/arm64. Google’s kvmCTF controlled vulnerability reward program — which accepts zero-day submissions for KVM and offers up to $250,000 for full guest-to-host escapes — received Januscape as a zero-day submission, Kim said. A related but distinct KVM x86 shadow paging use-after-free (CVE-2026-46113) was fixed in May 2026, making two shadow MMU use-after-frees in the same legacy code path within two months.

What this means for cloud operators, distribution maintainers, and on-premises hosts

  • Cloud operators: prioritize kernels that include commit 81ccda30b4e8 across multi-tenant x86 hosts that allow nested virtualization; consider disabling nested virtualization for untrusted tenants immediately.
  • Distribution maintainers and package teams: ensure backports are tracked by changelog rather than relying solely on uname -r, because the fix may appear under different package versions in vendor kernels.
  • On-premises administrators: treat exposed x86 KVM hosts with nested virtualization as high-priority patch targets and, if necessary, apply the temporary mitigation of disabling nested virtualization until patched kernels are deployed.

Januscape closes a long-standing gap in KVM's legacy shadow MMU code, but it also underlines the risk that long-lived code paths can harbor serious guest-to-host primitives. For any operator running untrusted guests with nested virtualization on x86, the immediate question is simple and actionable: do your kernels include commit 81ccda30b4e8 — and if not, can you patch or disable nested virtualization today?

Original story