Januscape — KVM guest-to-host escape tracking

Summary

How the exploitation chain works

Januscape is a use-after-free in KVM’s shadow MMU — the software page-table walker KVM uses when hardware two-dimensional paging (Intel EPT / AMD NPT) is not in play for a mapping, most notably for nested guests. It is the same class of bug that 0cb2af2ea66a closed for a mismatched GFN, reopened here through a mismatched role.

An attacker who controls a guest (or, locally, anyone who can open /dev/kvm) changes a PDE mapping from outside the guest so that a region backed by a 2 MiB shadow page (kvm_mmu_page with direct=1) is re-walked as a 4 KiB mapping, which needs a direct=0 page. kvm_mmu_get_child_sp() compares the GFN but not the role, so it reuses the existing direct=1 page. A leaf SPTE installed on the new path records an rmap entry under the walk-resolved GFN; but when that child is zapped, kvm_mmu_page_get_gfn() recomputes the GFN as sp->gfn + index (instead of consulting shadowed_translation[] / gfns[]), so it looks under the wrong GFN and fails to remove the rmap entry.

Deleting the memslot then frees the shadow page while the rmap entry survives. Any later walk of that GFN — dirty logging, an MMU-notifier invalidation, and so on — dereferences an sptep inside the freed page: a use-after-free the PoC turns into host code execution.

ℹ️ The vulnerable path is the shadow MMU, which on modern EPT/NPT hardware is exercised chiefly through nested virtualization. Disabling nested virt (kvm_intel.nested=0 / kvm_amd.nested=0) removes the guest-driven path for untrusted guests. Two ways in exist: a hostile guest escaping to host root, and — where /dev/kvm is world-readable/writable (the default on EL8 and later) — an unprivileged local user reaching the same code directly. Restricting /dev/kvm closes the second without touching the first. Only the kernel backport flips a verdict here; nested-virt and /dev/kvm posture are mitigations recorded in prose, not columns.

Vulnerable commit range

The reachable lifetime is therefore v2.6.36 (2010) through v7.1; ≥ 7.2 carries the fix. ARM64 KVM uses a different MMU and is not affected by this bug — see ITScape for the arm64 escape.

Patch status

The deciding fact per row is whether the kernel carries the 81ccda30b4e8 backport. Because the bug dates to v2.6.36, every kernel below is inside the affected window — there are no “predates the bug” rows here — so a row is :x: until its kernel ships the fix. /dev/kvm exposure and nested-virt defaults change who can reach the bug, not whether the kernel is fixed; they are recorded in prose.

The first group tracks the upstream kernel itself; the rest are a focused set of x86-64 distributions (other EL10-family systems — RHEL 10, CentOS Stream 10, Oracle Linux 10, CloudLinux OS 10 — and other systems named in the disclosures appear only in prose). Current kernel is the latest version observed in the row’s user-facing channel; First fixed is the first release or build carrying the fix, and Fixed since the date it first held (both stay — while a row is vulnerable).

Linux kernel

The fix reached Linus as v7.2-rc1 and the kernel CNA (CVE-2026-53359) backported it across the maintained stable lines on 2026-07-04. 7.0.y reached end of life at 7.0.14 without the backport. The pre-6.1 longterm lines (5.15.y, 5.10.y) carry the bug — the fix uses sp->gfns[] on those kernels — but have not received a backport as of this writing.

When verifying a tree directly, the fixed function is kvm_mmu_get_child_sp() in arch/x86/kvm/mmu/mmu.c; the fix adds a role comparison before reusing an existing child shadow page.

Debian

Debian’s linux is affected in every suite (the bug predates all of them); the security tracker’s CVE-2026-53359 record drove these assessments. bullseye (LTS) default linux kernel (5.10.x series) has not received the fix — upstream 5.10.y carries no backport and Debian has not issued an independent cherry-pick; 5.10.259-1 in bullseye-security remains vulnerable. The opt-in linux-6.1 package (bookworm’s 6.1 kernel rebuilt for bullseye) was updated to 6.1.177-1~deb11u1 in bullseye-security (2026-07-25), carrying the fix via the upstream 6.1.177 release. Debian keeps /dev/kvm owned root:kvm mode 0660, so the unprivileged local vector needs kvm-group membership there; the guest-escape vector is unaffected by that.

Proxmox VE

Proxmox ships its own Proxmox-built kernels (proxmox-kernel-*), so Debian’s fix status does not carry over. Each PVE release’s default kernel series (pinned by proxmox-default-kernel) and its other offered series get their own rows above: both defaults were fixed on 2026-07-08, the 6.17 series followed with advisory PSA-2026-00027-1, and the 6.11 and 6.14 series have had no release since before the disclosure, so they carry no Januscape cherry-pick. Proxmox publishes kernel updates to pve-no-subscription first; the enterprise repository receives the same kernels later. Proxmox VE is x86-only, so it does not appear in the ITScape (arm64) tracker.

An opt-in series is Proxmox’s preview of a likely next default, aimed at setups that need newer hardware support; an old series is one the release has moved past — a superseded default (PVE 9’s 6.17 and 6.14) or an opt-in overtaken by a newer one (PVE 8’s 6.11). Proxmox discontinues updates for superseded series once a short transition tail ends (the 6.17 fix above landed inside that tail), and every such PVE kernel series is long end-of-life on kernel.org, so a fix can only ever arrive as a Proxmox cherry-pick. A vulnerable old row is therefore unlikely ever to flip — the exit is rebooting into the release’s current default kernel.

Rocky Linux / RHEL family

The EL family ships /dev/kvm world-accessible by default (EL8 and later), so on those hosts any local user — not just a guest — can reach the bug; combined with the guest-escape path this is the higher-exposure case. RHEL-family kernels carry security backports without moving their upstream base version, so the version string alone cannot confirm a fix — the signal is an erratum. The fix flowed RHEL → AlmaLinux → Rocky:

• Standard kernel, EL10 / EL9 — Red Hat shipped RHSA-2026:36956 (RHEL 10, kernel 6.12.0-211.32.1.el10_2) and RHSA-2026:36957 (RHEL 9, kernel 5.14.0-687.24.1.el9_8); AlmaLinux rebuilt both on 2026-07-10, and Rocky 10 / Rocky 9 rebuilt the same NVRs (table above).
• Standard kernel, EL8 — Red Hat shipped RHSA-2026:39083 (2026-07-14, kernel 4.18.0-553.143.1.el8_10); AlmaLinux 8 rebuilt it as ALSA-2026:39083. Rocky 8 shipped the superseding cumulative 4.18.0-553.144.1.el8_10 as RLSA-2026:39179 (2026-07-15), which carries the backport.
• Real-time kernels (no table rows — a niche variant) — RHSA-2026:39983 (RHEL 9.2 E4S NFV, kernel-rt 5.14.0-284.181.1.rt14.466.el9_2, 2026-07-15) and RHSA-2026:39082 (RHEL 8 NFV, kernel-rt 4.18.0-553.143.1.rt7.484.el8_10, 2026-07-14).
• EUS / E4S / TUS streams (no table rows — the Rocky rows track the main RHEL releases) — RHSA-2026:39371 (RHEL 10.0 EUS, 6.12.0-55.88.1.el10_0), RHSA-2026:38902 (RHEL 9.6 EUS, 5.14.0-570.127.1.el9_6), RHSA-2026:37729 (RHEL 9.4 SAP US, 5.14.0-427.137.1.el9_4), RHSA-2026:40082 (RHEL 9.2 SAP US, 5.14.0-284.181.1.el9_2), and RHSA-2026:41229 (RHEL 8.8 TUS / SAP US, 4.18.0-477.154.1.el8_8, 2026-07-17).

Oracle Linux 10 and CloudLinux OS 10 are expected to track the RHEL fixes.

Amazon Linux

Each AL2023 kernel stream is its own row above; status is verified from the repodata updateinfo.xml (the per-CVE ALAS pages are JS-rendered and don’t fetch headlessly). The default 6.1 and kernel6.12 fixes are Amazon cherry-picks — their fixed builds sit below the upstream first-fixed releases — while kernel6.18’s fixed build tracks upstream 6.18.38.

AL2 (amzn2) is not tracked here: it reached end of support on 2026-06-30 — before this tracker existed — with no ALAS ever issued for this CVE, and AWS no longer provides security updates or bug fixes for AL2 core packages. All three of its kernel streams (4.14, plus 5.10 / 5.15 via amazon-linux-extras) are in-window and permanently vulnerable, and no fix is expected. The exit for an AL2 KVM host is migrating to AL2023 (or another patched distribution).

Detection

Is the running kernel in the affected window and missing the fix? Compare the running kernel against the Patch status table above — the Linux kernel rows for the upstream point releases, and your distribution’s row:

uname -r

Is this an x86 host? Januscape is x86-only (Intel or AMD); arm64 hosts are not affected by this bug:

uname -m

Is KVM in use, and is nested virtualization enabled? The shadow-MMU path is reached chiefly through nested guests; Y means nested virt is on:

cat /sys/module/kvm_intel/parameters/nested

On AMD hosts check the AMD module instead:

cat /sys/module/kvm_amd/parameters/nested

Who can open /dev/kvm? World access (e.g. crw-rw-rw-, the EL8+ default) exposes the local unprivileged vector; crw-rw---- root:kvm limits it to the kvm group:

ls -l /dev/kvm

Public PoC

The upstream PoC is in V4bel/Januscape; the published exploit demonstrates the host-crash path and is reported to reach root on both Intel and AMD. Do not run it on a system you are not authorised to test.

Mitigation

The real fix is a patched kernel (the 81ccda30b4e8 backport). Until one is installed, two interim measures each narrow the exposure.

Disable nested virtualization (removes the guest-driven path)

On an Intel host, turn nested virt off and reload the module (no running nested guests):

sudo modprobe -r kvm_intel

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

On an AMD host use kvm_amd in both commands. This blocks the shadow-MMU path for untrusted guests but does not close the hole for a workload that legitimately needs nested virtualization.

Restrict /dev/kvm (removes the unprivileged local vector)

Where /dev/kvm is world-accessible (EL8+), restrict it to a trusted group so unprivileged local users cannot open it directly:

sudo chmod 0660 /dev/kvm

Persist it with a udev rule:

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

This does not stop a hostile guest escaping — it only removes the local unprivileged path. Neither measure is a fix; the kernel hole remains until patched.

Risk notes

• Multi-tenant / untrusted-guest hosts: this is a guest-to-host-root primitive from inside an otherwise isolated VM — the headline risk for anyone running untrusted guests with nested virtualization enabled.
• EL8+ hosts (/dev/kvm world-accessible): any unprivileged local user can reach the bug directly, without needing a guest — self-hosted CI and shared multi-user hosts are directly in scope.
• Intel and AMD both: unlike many KVM escapes this is demonstrated on both vendors; there is no “AMD is safe” caveat.
• Backports available (CVE-2026-53359): the fix has landed in 7.1.3, 6.18.38, 6.12.95, 6.6.144, and 6.1.177, but distro kernels that have not yet adopted one of those releases remain vulnerable. Check the distribution row for your kernel.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

Last verified 2026-07-28.

References