Januscape: A 16-year-old Linux KVM flaw lets cloud VM tenants crash hosts and potentially escape guests. It affects Intel and AMD systems.
Security researcher Hyunwoo Kim has published details of a use-after-free vulnerability in Linux’s KVM hypervisor that allows code running inside a guest virtual machine to corrupt host kernel memory. The bug, tracked as CVE-2026-53359 and named Januscape, has been sitting in the kernel since August 2010. It affects both Intel and AMD processors, which makes it the first publicly documented guest-to-host KVM exploit that works across both architectures.
Kernel-based Virtual Machine (KVM) is a virtualization technology built directly into the Linux kernel that allows one physical computer to run multiple independent virtual machines (VMs).
Kim used it as a zero-day submission in Google’s kvmCTF program, which offers up to $250,000 for full guest-to-host escapes. The public proof-of-concept reliably panics the host kernel. A separate, complete exploit that achieves code execution on the host exists but hasn’t been released. Kim says that one is planned for the distant future.
KVM maintains its own internal set of page tables to track a guest’s memory layout. When it needs one of these tracking pages, it looks for an existing one to reuse. The problem is that it matched candidates by memory address alone and ignored the type of tracking page it was grabbing.
“Januscape is a use-after-free vulnerability in the shadow MMU emulation of KVM/x86. It can trigger the bug with guest-side actions alone to corrupt the host kernel’s shadow page, and it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization, particularly multi-tenant x86 public clouds (GCP, AWS, etc.).” states Kim. “In fact, Januscape was successfully used as a 0-day exploit in Google kvmCTF.”
This mistake confuses KVM about which memory page it is managing. Once KVM’s internal records become incorrect, the Linux kernel may handle invalid data, causing crashes or potentially allowing an attacker to gain control.
Most of the time, the kernel detects the corruption and shuts itself down immediately to prevent further damage. That’s the crash the public PoC triggers: a guest VM loads a kernel module and races for seconds to minutes until the host panics. Every other tenant VM on the same physical machine goes down with it. The more dangerous outcome happens when the freed tracking page gets allocated for a different use before cleanup runs. The cleanup then writes into memory it no longer owns. The attacker controls where that write lands, not what gets written, but that constrained primitive is enough to develop into full host code execution.
The attack requires root inside the guest VM and nested virtualization exposed by the host. Guest root is a standard condition on cloud instances: when you rent a VM, you get root on your own instance. The nested virtualization requirement is what matters architecturally, because even hosts that use hardware memory management by default have to fall back through the older shadow MMU code path when nested virtualization is active, and that’s exactly where the bug lives.
“Unlike the commonly published QEMU escape vulnerabilities, Januscape occurs in in-kernel KVM, so it is triggered independently of QEMU’s emulation. Because of this, it can also threaten large public clouds that implement and use their own virtualization stack.” continues the researcher.
That’s a meaningful distinction. Custom cloud virtualization stacks that strip out QEMU entirely aren’t protected by that fact.
On distributions like RHEL where /dev/kvm is world-writable with permissions set to 0666, an unprivileged local user could also use this bug to escalate to root without being inside a VM at all. Kim flags this but dismisses it as the lower-value use case. The guest-to-host cloud scenario is the one that matters. (His exact phrasing: doing so would be like paying gold for garbage. Fair enough.)
The fix is a one-line addition to kvm_mmu_get_child_sp(). The reuse condition now checks both the guest frame number and the role type together, so KVM only reuses a shadow page when both values match. Fixed stable kernel versions 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.
NVD hasn’t assigned a CVSS score yet. If you operate an x86 KVM host that accepts multi-tenant guests with nested virtualization enabled, confirm that commit 81ccda30b4e8 is present in your running kernel. Check the package changelog rather than relying on uname -r, because distribution backports may carry the fix under a different version number. If patching immediately isn’t possible, disabling nested virtualization with kvm_intel.nested=0 or kvm_amd.nested=0 removes the attack path for untrusted guests. ARM64 KVM hosts aren’t affected by Januscape specifically, though Kim’s earlier ITScape disclosure (CVE-2026-46316) covers a separate guest-to-host issue on that architecture.
“Januscape (CVE-2026-53359) covers the range from 2032a93d66fa (2010-08-01) to 81ccda30b4e8 (2026-06-16).” the researcher concludes “In other words, this vulnerability lay dormant for about “16 years”.”
Januscape is Kim’s third significant Linux kernel exploit in roughly two months. In May 2026, he disclosed Dirty Frag (CVE-2026-43284 and CVE-2026-43500), a page-cache write vulnerability chain that delivers reliable root on most major Linux distributions, extending the same vulnerability class as Dirty Pipe and Copy Fail. In June, he published ITScape (CVE-2026-46316), the first publicly demonstrated guest-to-host KVM escape on ARM64, exploiting a race condition in the virtual interrupt controller.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Januscape)
Source: SecurityAffairs
Source Link: https://securityaffairs.com/194868/security/januscape-16-year-old-linux-kvm-bug-enables-cloud-vm-escape-attacks.html
Introducing "Januscape" (CVE-2026-53359)