RC RANDOM CHAOS

Your hypervisor was never a wall

Januscape (CVE-2026-53359) is a 16-year-old use-after-free in KVM/x86's shadow MMU that lets a guest panic or take over the host on Intel and AMD.

· 3 min read
Your hypervisor was never a wall

Januscape, CVE-2026-53359, is a use-after-free in the shadow MMU emulation of KVM/x86. Hyunwoo Kim (@v4bel) found that a guest can corrupt the host kernel’s shadow page table through guest-side actions alone, and ran it as a 0-day against Google’s kvmCTF. The flaw was present from commit 2032a93d66fa on 1 August 2010 until the fix landed at 81ccda30b4e8 on 16 June 2026, about sixteen years in the tree.

Two things make it worse than the usual guest escape. First, the exploit research triggers on both Intel and AMD rather than one vendor’s extensions; Kim’s write-up describes it as the first guest-to-host work that fires on both. Second, the bug lives in in-kernel KVM, not in QEMU’s device emulation, so it is independent of the userspace VMM. A cloud running its own virtualization stack on top of KVM is still in scope. The named exposure is multi-tenant x86 public clouds that accept untrusted guests and expose nested virtualization, with GCP and AWS called out as examples.

The shadow MMU is where KVM maintains shadow page tables that mirror a guest’s page tables so the hardware can walk them directly, with reverse-mapping lists (the pte_list) tracking which shadow entries point at a given page. Januscape races those structures into a use-after-free on a shadow page. In the public proof of concept the result is a host-side panic: kernel BUG at arch/x86/kvm/mmu/mmu.c in pte_list_remove, in the qemu-kvm thread.

The PoC ships as a guest kernel module. You install headers, build it, unload kvm_intel (or kvm_amd on AMD) so the module can take the raw VMX/SVM state, then insmod poc.ko (with amd=1 on AMD). The race goes live and the host KVM panics within seconds to minutes. Loading a module needs guest kernel privilege, which on a rented cloud instance you usually have as root on your own VM. Without guest root, it has to be chained with a local privilege escalation such as Dirty Frag.

The panic is only the demonstration. Kim lists two impacts. The escape itself means a tenant who rented one instance can either panic the host and take down every co-tenant VM on that physical machine, or get code execution with root on the host and own the box and all its guests. The released code does the denial of service; a full escape exploit exists but is being held back, with release promised for “the very distant future.” There is also a local angle: on distributions like RHEL /dev/kvm is world-writable at 0666, so an unprivileged local user can turn Januscape into a reliable root LPE. Kim notes that path works but declined to document it.

It is x86 only. arm64 hosts are not affected by Januscape, but if you have not applied ITScape (CVE-2026-46316) your arm64 hosts are vulnerable to that, so patch it. The disclosure went through [email protected] under embargo; with the embargo lifted the exploit is on oss-security and the write-up is public.

If you run an x86 KVM host that takes multi-tenant guests and supports nested virtualization, or you rent an instance on one, confirm the host kernel carries the 81ccda30b4e8 fix.

Share

Keep Reading

Latest on the Wire

Full wire →

New signal daily · RSS

Stay in the loop

New writing delivered when it's ready. No schedule, no spam.