A significant use-after-free bug in the **Linux KVM** hypervisor, tracked as **CVE-2026-53359** and named '**Januscape**', has been publicly disclosed. This vulnerability allows a guest virtual machine to corrupt the shadow-page state of the host kernel, posing a severe risk to virtualized environments. Discovered and reported by security researcher **V4bel**, **Januscape** is notable for being the first publicly known guest-to-host exploit triggerable on both **Intel** and **AMD** architectures. The flaw resided undetected for approximately 16 years within the shadow MMU code shared by both CPU vendors. The public proof-of-concept (PoC), available on **GitHub**, demonstrates a host panic. However, **V4bel** claims a separate, unreleased exploit can leverage the same bug for full host code execution. The exploit was reportedly submitted as a zero-day in **Google's kvmCTF**, a KVM vulnerability reward program offering up to $250,000 for full guest-to-host escapes. ## How It Works **KVM** maintains its own set of page tables to mirror a guest's memory layout. When a tracking page is needed, **KVM** attempts to reuse an existing one. The core of the problem lies in how these pages were matched: solely by memory address, ignoring the type of tracking page. This oversight meant **KVM** could mistakenly reuse a tracking page of the wrong type, even if it shared the same memory address. This mix-up scrambles **KVM**'s internal records, leading to memory corruption. In most scenarios, the kernel detects this inconsistency and performs a self-shutdown to prevent further damage. This is the behavior observed with the public **Januscape** PoC: a guest VM can cause the entire host, and all other VMs running on it, to crash.  The more severe outcome occurs when a freed tracking page is reallocated before the kernel cleans it up. The subsequent cleanup operation then writes to memory it no longer owns. While an attacker only controls the write location, not the value, this limited control can be escalated to achieve arbitrary code execution on the host. ## Who Is Affected The vulnerable code was introduced in August 2010 (kernel 2.6.36 era) via commit `2032a93d66fa` and subsequently fixed by commit `81ccda30b4e8`, which was merged into the mainline kernel on June 19, 2026. Exploitation requires two key conditions from the guest side: root access within the VM (common in cloud environments) and nested virtualization enabled on the host. Even hosts using hardware **EPT** or **NPT** by default are forced into the legacy shadow MMU path when nested virtualization is active, which is where the bug resides. The exploit operates purely within the kernel's **KVM** component, requiring no cooperation from **QEMU** or userspace **VMM**. This vulnerability primarily impacts **x86** environments hosting untrusted guests with nested virtualization enabled. An attacker renting a single such instance could trigger a host panic, disrupting all other tenant VMs on the same physical machine. The full exploit, if utilized, could grant root access on the host, exposing all other guests to compromise. **V4bel** notes that on distributions like **RHEL**, where `/dev/kvm` is world-writable (0666), this bug could also serve as a local privilege escalation to root, though the guest-to-host path presents a higher impact. ## A Busy Period for the Researcher **Januscape** marks **V4bel**'s third **Linux kernel** exploit disclosure in approximately two months. In May 2026, he unveiled **Dirty Frag** (**CVE-2026-43284 / CVE-2026-43500**), a page-cache write vulnerability chain similar to **Dirty Pipe** and **Copy Fail**, leading to deterministic root access on major distributions. In June, he released **ITScape** (**CVE-2026-46316**), the first publicly demonstrated guest-to-host escape on **KVM/arm64**, exploiting a race condition in the virtual interrupt controller. **Januscape** now complements this by addressing the **x86** side, with a single trigger affecting both **Intel** and **AMD**. **Google** launched **kvmCTF** in 2024 due to **KVM**'s foundational role in **Android** and **Google Cloud**. Notably, another **KVM x86** shadow paging use-after-free (**CVE-2026-46113**), related to a distinct rmap mismatch, was patched in May 2026. This indicates a recent concentration of vulnerabilities within the same legacy code path. ## What to Do The fix is a concise, one-line addition to `kvm_mmu_get_child_sp()` that ensures a shadow page is reused only when both the frame number and the `role.word` match. **KVM** maintainer **Paolo Bonzini** authored the patch. Fixed stable versions were released on July 4, 2026, including: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260. While the **NVD** has not yet assigned a **CVSS** score, **SUSE** has rated it 8.8 (v3.1) / 9.3 (v4.0), underscoring the urgency of patching. If you operate an **x86 KVM** host that accommodates multi-tenant guests with nested virtualization enabled, it is crucial to verify that your kernel includes commit `81ccda30b4e8`. Be aware that distribution backports may carry the fix under a different version number, so consult package changelogs rather than relying solely on `uname -r`. For those unable to patch immediately, disabling nested virtualization (via `kvm_intel.nested=0` or `kvm_amd.nested=0`) eliminates the attack vector for untrusted guests. **ARM64** hosts are not affected by **Januscape**, though **ITScape** (**CVE-2026-46316**) addresses a separate **KVM/arm64** issue. The public PoC demonstrates a reliable host panic from a guest with a loadable kernel module, typically within seconds to minutes of racing. Treat exposed **x86 KVM** hosts with nested virtualization as high-priority patching targets. ## Update: Distribution Patch Status *Updated July 6, 2026.* The fix has reached mainline stable kernels. Downstream distributions are integrating the backport on their own schedules. Confirm status against your vendor's tracker. * **Debian**: Fixed in **DSA-6381-1** (July 5) for testing/trixie (`linux 6.12.95-1`) and unstable/sid (`7.1.3-1`). Stable (bookworm) and oldstable (bullseye) fixes are pending. * **SUSE / openSUSE**: Rated important. Status is Pending across most **SUSE Linux Enterprise 15 SP7** and **Leap** products, with kernel updates in QA. Apply via `zypper patch` once published. * **AlmaLinux, Rocky Linux, Oracle Linux**: These distributions rebuild from **RHEL** and will follow its kernel errata. Expect advisories once **Red Hat** releases its update. * **Red Hat**: Per-product status and the **RHSA** will be available on the **Red Hat CVE** page once released. * **Ubuntu**: **Canonical**'s per-release status is on the **Ubuntu CVE tracker**. As noted, the **NVD** had not scored the **CVE** at the time of writing, but **SUSE**'s high rating is a clear indicator to prioritize patching exposed hosts without delay.