Januscape: Linux KVM Guest-to-Host Vulnerability in x86 Shadow MMU
[image: 1783541008927-006e1164-01f5-4dfa-9392-bb1d42ea8ec3-image.jpeg]
Januscape is a newly disclosed Linux KVM vulnerability affecting x86 virtualization hosts. Tracked as CVE-2026-53359, the issue is a use-after-free bug in the KVM/x86 shadow MMU code path. The bug is especially relevant for KVM environments that expose nested virtualization to untrusted guest VMs.
At a high level, this is a guest-to-host isolation issue. A malicious guest with kernel-level privileges inside the VM can trigger corruption in the host kernel’s KVM shadow page state. The public proof-of-concept is a host panic/DoS, but the researcher says the same bug has also been turned into a full guest-to-host escape in a controlled environment. That full exploit has not been publicly released.
The vulnerability was discovered and reported by Hyunwoo Kim, also known as @v4bel, and was reportedly used as a zero-day submission in Google’s kvmCTF program.
The root cause is in how KVM reuses shadow MMU pages. KVM keeps shadow page tables that mirror guest-controlled paging structures in certain modes. When nested virtualization is enabled, KVM may need to shadow the nested EPT/NPT structures built by the guest hypervisor. This forces execution through the legacy shadow MMU path, even on modern systems that normally use hardware-assisted two-stage paging such as Intel EPT or AMD NPT.
The vulnerable function, kvm_mmu_get_child_sp(), reused an existing child shadow page based on a matching guest frame number, but did not also verify that the shadow page role matched. In practice, two shadow pages can refer to the same GFN while serving different purposes. One may be a direct split page derived from a large mapping, while another may be an indirect shadow page for a guest page table. Reusing the wrong one breaks KVM’s internal reverse-map accounting.
Once that accounting is wrong, KVM may fail to remove the correct reverse-map entry when tearing down shadow pages. Later, when the relevant memslot or shadow page is freed, stale pointers can remain. When KVM later walks or cleans up those structures, it can dereference or write through memory that has already been freed. The public PoC drives this into a host kernel panic through KVM’s own corruption detection path.
This is not a QEMU bug. The vulnerable logic is in the in-kernel KVM implementation. That distinction matters because mitigations focused only on QEMU device emulation do not address this issue.
The practical risk depends heavily on the environment. The most concerning targets are:
x86 KVM hosts
Multi-tenant virtualization platforms
Cloud, hosting, CI, lab, or VPS environments
Systems where guests are untrusted
Hosts exposing nested virtualization to guests
The attack requires root or equivalent kernel-level control inside the guest VM, because the published trigger is implemented as a guest kernel module. In many cloud or VPS scenarios, that is not a strong limitation, since customers commonly have root inside their own guest. The more important exposure condition is whether nested virtualization is available to the guest.
The issue affects both Intel and AMD x86 systems because the vulnerable shadow MMU logic is shared across the KVM/x86 implementation. ARM64 KVM hosts are not affected by Januscape, although they have had separate KVM escape-class issues such as ITScape.
The vulnerable code dates back to commit 2032a93d66fa from the Linux 2.6.36 era, around 2010. The mainline fix is commit 81ccda30b4e8, which updates the reuse check so KVM compares the shadow page role along with the GFN. In simple terms, KVM now only reuses a shadow page when both the frame number and the role match.
Fixed stable kernel versions reported include:
7.1.3
6.18.38
6.12.95
6.6.144
6.1.177
5.15.211
5.10.260
Distribution backports may not line up cleanly with upstream version numbers, so admins should check vendor advisories and package changelogs rather than relying only on uname -r.
For operators, this should be treated as a high-priority patching issue if nested virtualization is exposed to untrusted guests. The safest remediation is to update the host kernel to a vendor-patched build and reboot into the fixed kernel.
If patching cannot be done immediately, disabling nested virtualization is the main mitigation for the guest-to-host path:
kvm_intel.nested=0
kvm_amd.nested=0
After applying that mitigation, reboot the host or reload the KVM modules only if no guests are running. On production systems, rebooting into a known-good configuration is usually the cleaner approach.
Useful checks on a KVM host include:
uname -r
lsmod | grep '^kvm'
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
Inside a guest, nested virtualization exposure commonly shows up as vmx or svm CPU flags:
grep -Eo 'vmx|svm' /proc/cpuinfo | sort -u
For Proxmox, OpenStack, VPS, and general KVM operators, the key question is not simply “am I running KVM?” The better question is: “Can an untrusted guest reach nested virtualization on an unpatched x86 KVM host?”
If yes, this deserves immediate attention.
The public PoC is intended to demonstrate a host panic and should not be run on production infrastructure. A successful crash can take down all VMs sharing the same physical host. A failed crash also does not prove that the host is safe.
This is one of those bugs where the operational risk is narrower than a generic remote kernel RCE, but severe in the right environment. For single-user local KVM labs, the impact may be limited. For multi-tenant x86 KVM infrastructure with nested virtualization enabled, it is a serious guest isolation failure.
Sources:
Januscape researcher repository: https://github.com/V4bel/Januscape
Openwall oss-security disclosure: https://www.openwall.com/lists/oss-security/2026/07/06/7
NVD - CVE-2026-53359: https://nvd.nist.gov/vuln/detail/CVE-2026-53359
The Hacker News: https://thehackernews.com/2026/07/16-year-old-linux-kvm-flaw-lets-guest.html
