CVE-2026-53359: JanuScape and the KVM boundary

JanuScape matters because it crosses the boundary KVM is expected to enforce. This is not a QEMU device emulation flaw and it is not a bug that stops inside the attacking virtual machine. Guest controlled nested page tables reach an in kernel KVM path on the physical host.

At a glance

Severity and scoring

NVD currently carries the Linux CNA’s CVSS v3.1 score as a secondary metric and records public proof of concept exploitation through CISA’s SSVC data. Canonical notes that other published scores differ. The prerequisite is local from the guest’s perspective, but the security scope changes because successful exploitation reaches the host.

The boundary under attack

Modern KVM normally uses hardware assisted second stage translation and the TDP MMU. Nested virtualization changes the path. When L1 runs L2, the physical host must shadow the nested EPT or NPT tables that L1 controls. That work reaches the legacy shadow MMU where JanuScape lives.

The same shared x86 code handles this part of both Intel VMX and AMD SVM. The architecture specific page table bits differ, but the vulnerable reuse decision does not.

Same page number, wrong role

KVM stores shadow page metadata in struct kvm_mmu_page. Its role records how the page is being used. A direct shadow page can represent a large page split into 4 KB mappings. An indirect shadow page can represent a guest page table. Those roles have different accounting requirements.

The vulnerable kvm_mmu_get_child_sp() path checked whether an existing child shadow page had the requested guest frame number, but it did not also require the role to match. During a narrow race, a page created for a direct split could therefore be reused where an indirect page was required.

That role confusion breaks reverse map accounting. A leaf entry is registered under the frame number resolved by the guest walk, while teardown later computes a different frame number from the incorrect direct role. The reverse map entry survives after the shadow page is freed. Later code can dereference a pointer into that freed page.

The patch is small because the invariant is simple: reuse a child shadow page only when both its guest frame number and its complete role match. The security impact is large because the broken lifetime belongs to host kernel memory.

What the public proof demonstrates

The published proof of concept is a kernel module loaded in L1. It builds an L2 guest using raw VMX or SVM, arranges for one physical page to alternate between a large mapping and a page table, and uses multiple virtual CPUs to race the transition. The resulting reverse map mismatch reaches KVM’s corruption checks and can panic L0.

The researcher says the same use after free was turned into root code execution on a controlled host. That full escape is not public. This distinction matters: host denial of service is directly reproducible from the released code, while confidentiality and integrity impact rely on the reported private exploit and the power of the underlying memory corruption primitive.

The researcher also reports that JanuScape was used as a zero day in Google’s kvmCTF. CISA’s SSVC entry currently labels exploitation as proof of concept rather than active widespread exploitation.

Who is exposed

• KVM hosts on Intel or AMD x86_64 hardware running an affected kernel.
• Guests that can execute nested VMX or SVM and bring up their own L2 guest.
• Cloud or private virtualization platforms that expose nested virtualization to untrusted tenants.
• Privileged container workloads that receive usable access to /dev/kvm.

If nested virtualization is not exposed to a guest, the published attack path is not reachable from that guest. Unprivileged containers without KVM access are not the concern. A privileged container with access to the KVM device must be treated as a virtualization workload, not as an ordinary isolated process.

Check the host

Run the nesting check on the physical KVM host. A value of 1 or Y means nesting is enabled for that module. Missing files need interpretation because a module may be loaded later.

grep . /sys/module/kvm_{amd,intel}/parameters/nested
namei -l /dev/kvm
getfacl /dev/kvm
uname -r

• Inventory which tenants and services can request nested virtualization.
• Inspect group, ACL, and container access to /dev/kvm.
• Do not assume an idle host is safe. Services such as libvirt, Incus, LXD, or Multipass may allow VMs to be created later.
• Confirm that the running kernel, not merely an installed package, contains the fix.

Patch and mitigation

Use the fixed kernel supplied by the host’s distribution or cloud platform and reboot into it. NVD lists the first fixed releases in maintained upstream lines as 6.1.177, 6.6.144, 6.12.95, 6.18.38, and 7.1.3, with the mainline fix included in 7.2. Downstream kernels frequently backport security patches without matching those version numbers, so the distributor’s advisory remains authoritative for a packaged host.

If the host cannot be patched immediately, stop its VMs and disable nesting before reloading the vendor KVM module:

sudo rmmod kvm_amd
sudo rmmod kvm_intel
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
sudo modprobe kvm_amd
sudo modprobe kvm_intel

Operational warning: a KVM module can be unloaded only after every virtual machine using it has been shut down and every other KVM consumer has released it. Stop those workloads first, then unload the module. Disabling nesting can also break legitimate CI, sandbox, emulator, and lab use cases. Plan the maintenance window and verify the resulting module parameter.

The broader lesson

Nested virtualization is a capability and an attack surface. Compiling KVM support, exposing /dev/kvm, and allowing VMX or SVM inside a tenant are separate decisions. The safest default is to keep the boundary closed unless a workload genuinely needs it, then make the opt in visible and auditable.

JanuScape is also a reminder that hardware assisted paging does not remove every software shadow paging path. Once the platform supports an L2 guest, the L0 kernel may need to emulate translation structures controlled by L1. That less common path still carries the full trust burden of the hypervisor.

Original sources

• Hyunwoo Kim · JanuScape root cause, proof of concept, patch, and disclosure timeline
• Linux kernel commit 81ccda30b4e8 · require the shadow page role to match
• NVD CVE-2026-53359 · affected kernel ranges, CWE, CVSS, and SSVC
• Ubuntu CVE-2026-53359 · package status, CVSS v3.1, and advisories
• Canonical · exposure checks and nested virtualization mitigation
• oss-security disclosure · public coordination record