• Severity: CVSS 7.8 (Red Hat, Important) · CVSS 8.8 (SUSE)
  • Affected: Linux KVM/x86 hosts on Intel or AMD where nested virtualization is exposed; vulnerable code dates back to Linux 2.6.36
  • Patched: Upstream June 19, 2026; vendor rollout varies · Exploitation: Used as a zero-day in Google kvmCTF; public host-crash PoC available; full escape withheld

Introduction

Januscape, tracked as CVE-2026-53359, is a guest-to-host escape in the Linux kernel’s KVM/x86 shadow memory-management unit. Researcher Hyunwoo Kim publicly disclosed it on July 6, 2026 after reporting it privately to the Linux kernel security team on June 12.

The flaw is a use-after-free caused by shadow-page role confusion. Red Hat maps it to CWE-825, Expired Pointer Dereference; NVD had not assigned a CWE or CVSS score as of July 13. Vendor scoring differs: Red Hat rates it CVSS 7.8 and Important, SUSE rates it CVSS 8.8 under CVSS v3.1, and Ubuntu calculates CVSS v4.0 at 8.4. Different calculator, same uncomfortable conclusion: a malicious guest can cross the hypervisor boundary.

The guest-to-host path requires an x86 KVM host that exposes nested virtualization and an attacker with enough control inside a guest to load a kernel module or boot a supplied kernel. That usually means guest root, which cloud customers commonly have in their own instances. A second local-privilege-escalation path exists where an unprivileged host user can access /dev/kvm, especially on distributions that expose it with mode 0666.

Arm64 is not affected by Januscape, QEMU is not the vulnerable component, and cloud instances on providers that do not expose nested virtualization are not exposed to the guest-to-host path. This is an in-kernel KVM bug, so replacing QEMU does not make it disappear.

Attribution note: Januscape was discovered and reported by Hyunwoo Kim. His original technical write-up documents the root cause, public denial-of-service PoC, disclosure timeline, and withheld full escape. We’re summarising that work, not claiming it as our own.

What Happened

KVM maintains software-generated shadow page tables when an L1 guest runs its own L2 nested guest. The host, called L0 in virtualization terminology, must shadow the nested EPT page tables on Intel or NPT page tables on AMD. That path uses KVM’s legacy shadow MMU even when the physical host normally relies on hardware-assisted paging.

The vulnerable function, kvm_mmu_get_child_sp(), decides whether an existing child shadow page can be reused. Before the fix, it checked that the guest frame number, or GFN, matched. It did not check the page’s role.

That omission matters because the same GFN can represent two different jobs. A large 2 MB mapping split into 4 KB pages creates a direct shadow page with direct=1. A guest-controlled page-table mapping needs an indirect shadow page with direct=0. Januscape races KVM into asking for the second role while a child page from the first role is still linked. The GFN matches, the role does not, and vulnerable KVM reuses the wrong object.

From there, reverse-map and parent-pointer bookkeeping diverge. A shadow page can be freed while a stale pointer into it survives. Later cleanup or MMU activity dereferences or writes through that pointer, producing the use-after-free. The public PoC takes the simpler route: it drives the reverse-map mismatch into KVM_BUG_ON_DATA_CORRUPTION, causing the host kernel to panic.

KVM checked the shadow page’s address, but not its job description. Same desk, wrong employee, root-level consequences. :/

Where Januscape crosses the KVM trust boundary

Fig 1: Nested Virtualization Trust Boundary

Attack Sequence

The attacker begins with root inside an L1 guest on an Intel or AMD KVM host that exposes nested virtualization. A guest kernel module constructs a small L2 guest using raw VMX or SVM state, then builds nested page tables in L1-controlled memory.

One guest vCPU repeatedly toggles the same page-directory entry between a 2 MB huge mapping and a pointer to a 4 KB page table. Other vCPUs repeatedly run L2 and generate faults through that entry. This creates a race between KVM committing the new PDE value and removing the old shadow link.

When a fault lands inside that window, the host’s shadow MMU requests an indirect page while the old direct page is still attached. The vulnerable reuse check sees the matching GFN and accepts the object without comparing its role. A leaf entry is then recorded under the real GFN, but later removal computes a different GFN using the direct-page assumption.

The public PoC turns that mismatch into a host panic within seconds to minutes. Kim also demonstrated a full guest-to-host escape in a controlled environment by converting the stale-pointer condition into a fixed-value write against reallocated kernel memory. That weaponised escape has not been released publicly. There is no public evidence of malicious exploitation outside Google kvmCTF as of July 13, 2026.

Shadow-page role confusion state machine

Fig 2: Shadow-Page Role Confusion State Machine

Why This Is Especially Dangerous

Januscape attacks the boundary a hypervisor exists to enforce. Successful exploitation can give an attacker far more than control of one rented VM:

  • Host-root code execution: a malicious guest can execute code in the host’s most privileged context.
  • Cross-tenant compromise: once the host is owned, other guests, their memory, credentials, storage and network traffic become targets.
  • Host-wide denial of service: the public PoC can panic the physical host and take every co-resident VM down with it.
  • Local root without an existing VM: where /dev/kvm is writable by ordinary users, a local attacker can create the required KVM context and turn the same bug into privilege escalation.
  • Intel and AMD exposure: the vulnerable shadow-MMU code is shared across VMX and SVM, so changing CPU vendor is not a mitigation.
  • VMM independence: the flaw lives in the host kernel, not QEMU, and can affect operators using custom userspace virtualization stacks.

Multi-tenant KVM clouds, hosting providers, CI platforms that offer nested VMs, security sandboxes, developer workstations and lab platforms are the highest-priority targets. Systems where only trusted administrators control every guest are lower risk, but a host panic from one compromised guest is still not a charming failure mode.

Affected Versions

The vulnerable logic was introduced by commit 2032a93d66fa on August 1, 2010 and remained present for roughly 16 years. Upstream fixed it by adding a role.word comparison in commit 81ccda30b4e8. Enterprise distributions commonly backport kernel changes, so package versions from the distribution advisory take precedence over the upstream version number.

BranchVulnerable VersionsFix Available
Legacy vendor branches below Linux 6.1From 2.6.36; vendor kernels without the backportVendor backport required
Linux 6.1.y6.1.176 and earlier6.1.177
Linux 6.6.y6.6.143 and earlier6.6.144
Linux 6.12.y6.12.94 and earlier6.12.95
Linux 6.18.y6.18.37 and earlier6.18.38
Linux 7.1.y7.1.2 and earlier7.1.3
MainlineBefore commit 81ccda30b4e8Included from 7.2-rc1

Selected distribution status as of July 13, 2026:

DistributionVulnerable VersionsFix Available
AlmaLinux 8Kernels before 4.18.0-553.141.2.el8_10Production update available
AlmaLinux 9Kernels before 5.14.0-687.23.1.el9_8Production update available
AlmaLinux 10Kernels before 6.12.0-211.31.1.el10_2Production update available
RHEL 9 and 10Affected package streams listed by Red HatUpdates published in RHSA-2026:36957 and RHSA-2026:36956; reboot required
Debian 13 TrixieBefore 6.12.95-1Fixed in the security repository
Debian 12 Bookworm and 11 BullseyeCurrent tracker versions still vulnerableFix pending in the Debian tracker
Ubuntu 14.04 through 26.04Ubuntu currently lists the relevant linux packages as vulnerableFix pending; disable nesting meanwhile

Not affected by this CVE: Arm64 and other non-x86 KVM hosts, x86 KVM deployments where nested virtualization cannot be reached for the guest-to-host path, and systems where KVM is not loaded or accessible. Do not confuse Januscape with ITScape, CVE-2026-46316, which separately affects KVM/arm64.

Mitigations

1. Patch the host kernel, then reboot

Apply the kernel update from your distribution. The update must be installed on the physical KVM host; updating only the guest does not repair the host’s shadow MMU.

For RHEL-family systems:

sudo dnf clean metadata
sudo dnf upgrade
sudo reboot

For Debian-family systems, install a fixed package only after the vendor tracker shows one for your release:

sudo apt update
sudo apt full-upgrade
sudo reboot

Confirm the fixed kernel is running, not merely installed:

uname -r

Older enterprise branches may need the Januscape fix and its companion shadow-paging fix, CVE-2026-46113. CloudLinux explicitly ships both together. Follow the distribution advisory rather than attempting to cherry-pick a single commit into a production kernel.

2. Disable KVM entirely where virtualization is not required

If the server does not run KVM guests, remove the attack surface. Stop dependent services first, then unload the CPU-specific module and KVM core:

# Intel
sudo modprobe -r kvm_intel kvm

# AMD
sudo modprobe -r kvm_amd kvm

Block the CPU-specific modules from loading again until the host is patched:

printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' 
  | sudo tee /etc/modprobe.d/disable-kvm.conf

Verify that no KVM module or device remains:

lsmod | grep kvm
ls -l /dev/kvm

3. Disable nested virtualization on hypervisors awaiting a patch

This blocks the guest-to-host route but may break legitimate nested-VM workloads. Live-migrate or stop guests before reloading KVM modules.

Check the current setting:

grep . /sys/module/kvm_{amd,intel}/parameters/nested 2>/dev/null

A value of 1 or Y means nesting is enabled. Disable it for both implementations:

echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/nested.conf
echo 'options kvm_intel nested=0' | sudo tee -a /etc/modprobe.d/nested.conf

Reload the relevant module during a maintenance window or reboot, then run the check again. Missing parameter files do not prove permanent safety because the module may load later.

4. Restrict access to /dev/kvm

This closes the unprivileged local-user path; it does not stop a malicious existing guest from attacking a vulnerable hypervisor.

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' 
  | sudo tee /etc/udev/rules.d/65-kvm.rules
sudo udevadm control --reload-rules
sudo udevadm trigger /dev/kvm

Audit the device and the group:

namei -l /dev/kvm
getfacl /dev/kvm
getent group kvm

Remove users and services that do not genuinely need to create hardware-accelerated VMs. A mode of 0660 is only useful if the kvm group is not treated like a community noticeboard.

Indicators of Compromise

No malicious IP addresses, domains, payload hashes or stable file-based indicators have been published for Januscape as of July 13, 2026. The public artifact is a denial-of-service PoC, while the full escape remains private. Defenders should therefore hunt for behaviour and crash evidence rather than pretend this kernel race comes with a neat domain blocklist.

On the host device

  • Search kernel logs for gfn mismatch under direct page, pte_list_remove, KVM_BUG_ON_DATA_CORRUPTION, kernel BUG at arch/x86/kvm/mmu/mmu.c, and unexpected host panics where the current process is qemu-kvm.
  • Investigate sudden KVM-host crashes preceded by heavy nested virtualization activity from one tenant.
  • Review unexpected changes to KVM module options, module loads, /dev/kvm permissions and membership of the kvm group.
  • Correlate suspicious guest activity with a guest loading an unfamiliar kernel module or rebooting into an attacker-supplied kernel.
sudo journalctl -k --since '7 days ago' 
  | grep -Ei 'gfn mismatch under direct page|pte_list_remove|KVM_BUG_ON_DATA_CORRUPTION|kernel BUG.*kvm/mmu/mmu|qemu-kvm'

In traffic and control-plane logs

  • There is no Januscape-specific network signature. Review cloud and virtualization control-plane logs for the tenant, instance owner, console sessions and management-source IPs associated with an unexplained host failure.
  • Correlate repeated host crashes, migrations or instance recreation with the same guest identity. The PoC is race-based and may be retried before it lands.
  • Treat outbound connections or credential use from a host after a suspicious KVM event as possible post-exploitation, not as proof of Januscape by itself.

Configuration integrity

  • Record and monitor /sys/module/kvm_intel/parameters/nested and /sys/module/kvm_amd/parameters/nested.
  • Alert on /dev/kvm becoming world-writable or gaining unexpected ACL entries.
  • Track changes under /etc/modprobe.d/, /etc/udev/rules.d/ and virtualization service definitions.
  • Verify that the running kernel matches the fixed vendor package after every reboot or failover.

Because the disclosure is recent, watch the Linux kernel record, your distribution advisory and Kim’s Januscape repository for new exploit or detection information.

References