Skip to main content
Version: Next

Januscape (CVE-2026-53359)

VM-to-host escape

Januscape is a VM-to-host escape in the Linux kernel's KVM/x86 subsystem. A tenant who has root inside their own VM can corrupt the host kernel and, in the worst case, run code as root on the hypervisor, breaking isolation from every other VM on that host. Because VirtFusion hypervisors run tenant workloads on KVM, any affected hypervisor should be patched and rebooted as a priority.

Summary​

FieldDetail
CVECVE-2026-53359
NicknameJanuscape (part of "The KVM Escape Trilogy", alongside ITScape and Zapscape)
ComponentLinux kernel, KVM/x86 shadow MMU
ClassUse-after-free (UAF)
ImpactVM-to-host escape. The public proof-of-concept panics the host; the researcher reports a private variant that achieves code execution as root on the host.
SeverityImportant
AgeIntroduced by commit 2032a93d66fa (2010-08-01). Roughly 16 years of exposure.
Upstream fixCommit 81ccda30b4e8 (merged mainline 2026-06-16)
ArchitecturesBoth Intel and AMD. Unlike Zapscape, there is no additional Intel-only EPT condition.
Where it appliesHypervisors running KVM VMs. This does not affect the VirtFusion control server.

Am I affected?​

The vulnerability lives in the host kernel on your hypervisors. It is not a VirtFusion application flaw and does not affect the control server. You are potentially exposed if all of the following are true:

  • A hypervisor runs an unpatched Linux kernel that includes the vulnerable shadow-MMU code, which has been present since 2010.
  • VMs are able to use nested virtualization.
  • A VM is controlled by an untrusted party with root inside the VM, which is the normal situation in a multi-tenant hosting environment.

Januscape is triggerable on both Intel and AMD hosts with no extra CPU condition, which makes it broader in reach than Zapscape.

Technical details​

Januscape is a use-after-free in KVM's shadow MMU caused by a shadow-page role mismatch. When a page directory entry (PDE) that maps a large 2 MB page is changed to point to a non-leaf 4 KB page, KVM reuses an existing kvm_mmu_page with direct=1 instead of creating one with direct=0. The resulting rmap entry survives memslot deletion, so KVM later dereferences shadow-page memory that has already been freed. VM-side actions are enough to drive this and corrupt the host kernel's shadow page state, which is what breaks the isolation boundary between a VM and its host.

The bug was serious enough to be used as a working zero-day against Google's kvmCTF, earning the top $250,000 bounty tier reserved for a complete VM-to-host escape.

The upstream fix (81ccda30b4e8) corrects the shadow-page handling so the stale entry can no longer be reused after it is freed.

Patch the companion CVE too

Fully closing the KVM shadow-paging hole requires both CVE-2026-53359 and its companion CVE-2026-46113. Patching only one leaves shadow paging exposed. Confirm that both CVE IDs appear in your updated kernel package changelog, not just that the package version increased.

Patch status by distribution​

VirtFusion is supported on Debian 12/13, Ubuntu 22.04/24.04, and RHEL-family 9/10 (AlmaLinux / Rocky). The table below tracks the fix for those distributions.

This is a point-in-time snapshot

The state below reflects 2026-08-08. Distribution patch status changes as errata ship. Always confirm against the vendor's live security tracker (linked in References) before deciding a host is safe.

DistributionStatusFixed kernel / advisory
Debian 13 (trixie)Patchedlinux 6.12.101-1 (DSA-6381-1)
Debian 12 (bookworm)Patchedlinux 6.1.180-1 (DSA-6381-1)
Ubuntu 24.04 LTS (noble)Not yet fixedFix in progress
Ubuntu 22.04 LTS (jammy)Not yet fixedFix in progress
RHEL 9 / AlmaLinux 9 / Rocky 9Patchedkernel-5.14.0-687.23.1.el9_8 or newer
RHEL 10 / AlmaLinux 10 / Rocky 10Patchedkernel-6.12.0-211.31.1.el10_2 or newer

Debian​

  • Debian 13 (trixie): Fixed in linux 6.12.101-1 (DSA-6381-1). Update and reboot.
  • Debian 12 (bookworm): Fixed in linux 6.1.180-1 (DSA-6381-1). Update and reboot.

Ubuntu​

  • Ubuntu 24.04 LTS (noble) and 22.04 LTS (jammy): No fixed linux package released yet at the time of writing; the fix was in progress across the generic and derivative kernels (linux-aws, linux-azure, linux-gcp, linux-oracle, and so on). Apply the interim mitigation and update once the USN is published.

RHEL family (AlmaLinux / Rocky)​

  • 9 (el9): Fixed. Install kernel-5.14.0-687.23.1.el9_8 or newer and reboot. RHEL 9, AlmaLinux 9, and Rocky 9 all shipped the fix.
  • 10 (el10): Fixed. Install kernel-6.12.0-211.31.1.el10_2 or newer and reboot.

Confirm both CVE IDs (see the companion-CVE note above) are listed in the package changelog before treating a host as fixed.

Remediation​

The fix is a host kernel update followed by a reboot on every hypervisor. A kernel update does not take effect until the host is running the new kernel, so the reboot is required.

apt-get update -y && apt-get install --only-upgrade linux-image-amd64 -y
# Reboot into the new kernel once VMs are migrated/stopped:
reboot

After rebooting, confirm the host is running a fixed kernel:

uname -r

Compare the output against the fixed version in the table above, and check the changelog for both CVE-2026-53359 and CVE-2026-46113.

Mitigations if you cannot patch yet​

If a fixed kernel is not yet available for a host, reduce exposure until you can update.

Disable nested virtualization on hypervisors that do not need it. This removes the primary exploitation path. VirtFusion uses the stock distribution libvirt/KVM, and on current kernels the nested module parameter defaults to enabled for both kvm_intel and kvm_amd, so hosts are exposed by default.

The nested parameter cannot be changed while kvm_intel / kvm_amd is loaded, and the module cannot be unloaded while any VM is running. The reliable sequence is therefore to set the value in the modprobe.d config, then reboot the host so the module reloads with nested=0.

Nested can be enabled two ways: by an active options ... nested=1 line in a modprobe.d file, or, when nothing sets it, by the kernel module's own default (which is nested=1 on current kernels). Handle whichever applies. When you do set it in a file, correct the value at its source rather than adding a second override file: modprobe reads every .conf file in the modprobe.d directories in lexicographic filename order and the last value for a repeated parameter wins, and a plain name like kvm.conf sorts after any numeric-prefixed file, so a separate override is easily outranked.

First, find any active (uncommented) line that sets nested. Commented example lines, such as those AlmaLinux ships in /etc/modprobe.d/kvm.conf, do not count:

grep -RHn '^[^#]*nested' /etc/modprobe.d/ /run/modprobe.d/ /usr/lib/modprobe.d/ /lib/modprobe.d/ 2>/dev/null

If an active line sets nested=1 (some VirtFusion hosts ship /etc/modprobe.d/kvm.conf this way), change its value to 0:

sed -i 's/nested=1/nested=0/' /etc/modprobe.d/kvm.conf

If the command returns nothing, nested is on by the kernel default and no file is setting it. Add an active line that disables it, matching your host's CPU vendor:

echo "options kvm_intel nested=0" >> /etc/modprobe.d/kvm.conf

The change only takes effect once the module reloads, which means a reboot:

reboot

After the host is back up, confirm nested virtualization is off. This sysfs value is the effective setting regardless of what produced it, so it is the definitive check. 0 means disabled:

cat /sys/module/kvm_intel/parameters/nested

If it still reads 1 after a reboot, the value is being forced on the kernel boot command line, which the modprobe.d config cannot override. Remove any kvm_intel.nested=1 / kvm_amd.nested=1 from your bootloader config (/etc/default/grub), regenerate the config, and reboot.

note

Disabling nested virtualization requires a host reboot, which is also what applies a kernel update. If a fixed kernel has already shipped for your distribution, it is simpler to patch and reboot once (see Remediation) instead. Turning off nested is intended for hosts where no fixed kernel is available yet. It lowers the likelihood of exploitation but does not remove the vulnerability.

References​

Last updated on