Security researcher Hyunwoo Kim (@v4bel) has disclosed CVE-2026-53359, nicknamed “Januscape” — a use-after-free in the Linux KVM hypervisor’s shadow MMU that has sat unnoticed in mainline since a commit in August 2010. A guest VM with root inside itself and nested virtualization enabled can corrupt host kernel memory, reliably panic the host, and — per the researcher’s own claim of a separate, unreleased exploit — potentially achieve full code execution on the hypervisor. It affects both Intel (VMX) and AMD (SVM) backends, making it the first publicly documented guest-to-host KVM escape research that fires on both vendors from a single root cause.
What’s broken
KVM implements “shadow paging” for guests that don’t get hardware-assisted nested paging support — most commonly nested virtualization scenarios, where an L1 guest runs its own L2 guest and KVM has to shadow the L1’s page tables. The function kvm_mmu_get_child_sp() decides whether an existing shadow page (kvm_mmu_page) can be reused for a new mapping. It only ever compared the guest frame number (gfn) of the request against the cached shadow page — never the page’s role, a struct that encodes attributes like whether the page maps a huge page (direct=1) or a 4KB leaf mapping (direct=0).
That’s the bug. If a guest first establishes a 2MB huge-page mapping (creating a shadow page with direct=1) and then forces the same region to split into 4KB pages (needing a shadow page with direct=0), kvm_mmu_get_child_sp() reuses the original direct=1 page instead of allocating a fresh one — because gfn matched and role was never checked.
Installing a leaf SPTE on the 4KB path records an rmap entry keyed by the gfn from that walk. But when that shadow page is later zapped, its parent still has direct=1, so kvm_mmu_page_get_gfn() computes the gfn as sp->gfn + index instead of consulting sp->shadowed_translation[] — the correct source for non-direct pages. The rmap entry for the real mapping never gets cleaned up. When the memslot is later dropped, the shadow page is freed while a stale rmap entry pointing into it survives. Anything that subsequently walks that gfn — dirty-logging, an MMU-notifier invalidation, ordinary EPT/NPT maintenance — dereferences a freed sptep. Use-after-free, inside the host kernel, triggered entirely by guest behavior.
Exploitation
The public PoC loads a kernel module inside a guest VM, builds nested page tables, and races two threads: one flips a region between huge-page and page-table mappings, the other continuously triggers page faults from a nested guest VM. The race widens a non-atomic window in KVM’s page-tracking logic long enough to reliably hit the flawed reuse path. Kim reports the PoC reliably panics the host within seconds to minutes of racing, and states a further, unreleased weaponization turns the crash primitive into host code execution.
Impact
Requirements are narrow but common in real deployments: attacker needs root inside a guest VM, and the host must have nested virtualization enabled (kvm_intel.nested=1 / kvm_amd.nested=1). That’s the default posture for a meaningful slice of public cloud and virtualization-heavy hosting — nested virt underlies things like running Kubernetes-in-VMs, CI runners that spin up VMs, and any customer-facing “bring your own hypervisor” offering. Since the bug lives in the shared shadow-MMU code path rather than a vendor-specific EPT/NPT implementation, it isn’t limited to Intel or AMD — a single trigger threatens guest-host isolation on both. Any multi-tenant environment that permits nested virtualization for customer workloads (some public cloud VM tiers, self-hosted Proxmox/oVirt/OpenStack clusters, CI infrastructure that nests VMs) should treat this as a hypervisor-breakout risk, not just a DoS.
Mitigation
Fixed stable kernel versions shipped 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 fix is a one-line change to kvm_mmu_get_child_sp() that adds a role.word comparison alongside the gfn check, so a shadow page is only reused when both match.
If you can’t patch immediately: disable nested virtualization on hosts that run untrusted guests — kvm_intel.nested=0 or kvm_amd.nested=0 — which removes the attack path entirely, since the bug requires nested virt to reach the vulnerable shadow-paging code. Check with your cloud provider or virtualization platform vendor (Proxmox, oVirt, OpenStack/QEMU-KVM distributions) for backported kernel packages; several downstream distros have already shipped updates. Audit which of your VM offerings expose nested virtualization to tenants and consider disabling it as a stopgap for any host you can’t patch this week.
References: The Hacker News writeup, Januscape technical writeup on GitHub, CVE-2026-53359 kernel fix details.