Vulnerability Research
KVM Checked the Room Number, Not the Role — Reconstructing Januscape (CVE-2026-53359)
Januscape (CVE-2026-53359) lets KVM/x86 reuse a same-GFN shadow page after its role changes, leaving rmap state that can outlive the page; platforms exposing untrusted nesting should reboot L0 into a current vendor-supported fixed kernel—7.1.5, 6.18.40, 6.12.98, 6.6.145, or 6.1.178 for direct kernel.org followers on July 27, 2026—and suspend nested scheduling until code, L2, migration, and log checks pass.

In this article
The Januscape demonstrator published on July 6, 2026 makes an L1 guest trigger an L0 host panic through nested-virtualization state. The failure belongs to arch/x86/kvm/mmu/mmu.c in the host kernel. L1 first uses one guest frame as the target of a 2 MiB mapping and then uses that same frame as an L2 page table. Old KVM sees an equal GFN and gives the existing direct shadow page to a new indirect walk. The page is still allocated at the mistaken reuse; a stale rmap entry and the eventual host UAF turn that identity error into lifetime corruption.
The public demonstrator establishes a host panic. The researcher also reports working guest-to-host code execution and describes a primitive that writes one fixed value to an attacker-influenced slot inside a page; the complete escape chain was not published. Reachability requires control of the L1 kernel or an equivalent ability to construct VMX/SVM state, start L2, and program the nested EPT/NPT. An Internet listener, an ordinary application account, or a normal shell alone supplies none of those capabilities. Exposure depends on whether the platform grants nesting to an untrusted L1.
Four objects carry the rest of the investigation. A GFN, or guest frame number, identifies a guest-physical page. A shadow page is a page-table page managed by L0 KVM. An SPTE is one mapping entry inside a shadow page. An rmap is the reverse index from a GFN back to the SPTEs that map it. The literal translation sequence is: an L2 virtual address passes through L2 page tables to an L2 guest-physical address; L1's nested EPT/NPT interprets that address as an L1 guest-physical address; L0 then combines its shadow walk with host memory backing to reach the final host page. Januscape corrupts L0's decision to reuse a shadow page during that combined translation.
1 Decide L0 state, nesting exposure, and scheduler eligibility first
A security work order needs three immediate answers: which physical hosts are executing KVM/x86, which running kernel builds contain the complete role repair, and which L1s are allowed to create L2. Updating an L1 or L2 kernel leaves the host's kvm_mmu_get_child_sp() unchanged. A QEMU device package does not own this shared shadow-MMU branch. The physical host is the upgrade, restart, and acceptance unit.
Intel nodes commonly expose the effective switch at /sys/module/kvm_intel/parameters/nested; AMD uses /sys/module/kvm_amd/parameters/nested. Record that value together with /etc/modprobe.d, the kernel command line, initramfs, host-image recipes, control-plane capabilities, instance flavors, and scheduler labels. Sysfs describes the loaded module while persistent sources determine the next load. Current reachability and post-restart state require both records.
1.1 Code and response map: reject the old child when role differs
1.2 Nested translation brings the legacy shadow MMU back into the critical path
L0 owns the physical CPU and memory. L1 is its guest, and L2 is a machine started by L1. Intel expresses the nested capability through VMX/EPT; AMD uses SVM/NPT. L1 can present L2 with an address space that looks physical, yet only L0 can install mappings into real hardware. L0 has to combine the L2 address, L1's nested translation, and the actual host backing page.
Ordinary L0-to-L1 translation can use hardware EPT/NPT and the direct TDP MMU. The nested translation supplied by L1 enters a guest_mmu whose root role is non-direct, so KVM still executes a legacy shadow walk. Settings such as ept=1, npt=1, or a TDP-MMU-enabled build describe the conventional path. Nesting exposure and the non-direct guest MMU describe Januscape reachability.
The capability may come from a service. L1 can hold /dev/kvm directly, or libvirt, Incus/LXD, a privileged sidecar, or a platform VMM API can create L2 for it. An estate record should cover device ACLs, service authorization, guest-visible VMX/SVM CPUID, image type, tenant trust, and scheduler eligibility. One legitimate L2 start test checks whether the control-plane claim matches the capability actually exposed.
A host can carry ordinary VMs and nested VMs at the same time. The principal able to trigger the path is limited to an L1 with nesting, while a host panic interrupts every workload on that physical node. Priority therefore combines the running build, nesting, L1 kernel-equivalent control, and critical co-residency in one host record.

2 One GFN can successively carry two incompatible roles
struct kvm_mmu_page stores both gfn and role. The title's room-number analogy has one limited purpose: GFN says which guest frame anchors the page, while role says how KVM must interpret the SPTEs inside it. Role includes level, access, quadrant, passthrough, and direct fields. Those bits select lookup, translation-recording, and teardown algorithms.
Januscape preserves GFN equality while changing use. The first use comes from splitting a 2 MiB huge mapping into 4 KiB entries, which creates a direct=1 shadow page. The second comes when L1 repurposes the same frame as a lower-level page table, which requires a direct=0 indirect shadow page. Guest physical memory carries no permanent hardware label for “data” or “page table.” The current page-table walk establishes the use.
2.1 A direct split derives each leaf GFN from position
When a nested PDE describes a 2 MiB leaf and its target GFN is already shadowed, disallow_lpage prevents KVM from retaining a large mapping. kvm_mmu_hugepage_adjust() lowers the fault to 4 KiB granularity, and KVM creates a direct shadow page for the consecutive region. SPTE zero maps the base GFN; later entries calculate their offset from index and level.
Commit 2032a93d66fa stopped allocating a redundant per-entry GFN array for direct MMU pages in 2010. The optimization relies on a precise invariant: the page remains direct for its lifetime, and insertion and removal both use the base-plus-index rule. The Linux CNA names that commit as the affected design lineage because later wrong-role reuse breaks the invariant.
Direct role also carries level and access. Level determines how many guest frames an index spans; access records the permissions being shadowed. Downstream consumers choose algorithms from those fields, making role part of object identity and more than a debugging label.
2.2 An indirect page preserves the translation found by each walk
After L1 changes the nested PDE from a huge leaf to a page-table pointer, the same frame contains lower-level guest entries. Each entry can point to an arbitrary GFN, so index no longer identifies the target. A correct indirect shadow page uses direct=0 and preserves the translation resolved by the walk. Newer lines use shadowed_translation[]; older lines have structures such as gfns[].
Each page type has a consistent algorithm. Direct removal reconstructs a GFN from base and index. Indirect removal retrieves the translation saved when the leaf was installed. Once an indirect walk receives a direct page, installation records the Q GFN actually named by the guest page table, while the page identity later makes removal calculate a member of the consecutive split range. The error survives the original fault and enters teardown.
role.word packages the complete semantics into one comparable value. The direct bit is the visible difference in the published construction, and level, access, or quadrant can also change page meaning. Comparing the whole word makes the reuse contract match full identity and covers future role differences through the same check.

3 GFN-only reuse sends a new walk into the old direct child
kvm_mmu_get_child_sp() chooses reuse or acquisition when a shadow walk needs the page below a parent SPTE. Existing-child reuse is a page-fault hot-path optimization. If the parent already links the correct page, the function returns ERR_PTR(-EEXIST) and the caller keeps walking through that link. Other requests go to kvm_mmu_get_shadow_page() to find or create a page with the requested identity.
3.1 The vulnerable parent returns -EEXIST before requested role exists
The vulnerable parent's pinned lines 2459–2470 check that the parent SPTE is present, the SPTE is not a large leaf, a child can be resolved, and the child's GFN equals the requested GFN. Four true conditions return -EEXIST. The call to kvm_mmu_child_role(sptep, direct, access) follows that branch, so the requested role never participates in the shortcut.
All four old conditions are true in the Januscape state. The old direct child is still linked, the new fault asks for the same GFN, and the child remains allocated. The missing condition is child->role.word == requested_role.word. The caller follows the link and installs a leaf from an indirect walk inside a direct page. A live object is being managed under the wrong semantics at this first failure point.
Neighboring commit 0cb2af2ea66a had already required the existing child's GFN to match, closing the unexpected-GFN UAF. Januscape deliberately keeps the GFNs equal and changes only role. A complete downstream backport therefore has two behaviors: a different GFN rejects the child, and an equal GFN with a different role also rejects the child.

3.2 Writer and faulters make a new PDE and an old link visible together
L1 is allowed to modify the nested page table it supplies to L2. KVM page tracking observes those writes and zaps obsolete shadow links, but the guest-page-table value becoming visible and the old child completing retirement are separate events. The Januscape writer repeatedly changes one PDE between a huge leaf and a page-table pointer. Multiple faulters keep L2 accessing the address and generating shadow faults.
The successful order is concrete. A huge interpretation has already created the direct child. The writer stores the table pointer. A faulter reads the new table interpretation. Tracking has not yet removed the direct child from the parent SPTE. The GFN-only branch then returns -EEXIST. Several faulters add scheduling opportunities and contend on MMU locking, widening the interval. The public report records triggering times from seconds to minutes because scheduling, vCPU count, and host speed vary.
The MMU lock protects structural integrity here: the parent link and child pointer are valid when observed. Object suitability needs a separate role check. A complete concurrency protocol protects the pointer structure and validates that the cached object still fits the current request. Januscape lacks the semantic validation.
A production host should use version, vendor-backport, booted-kernel, nesting, and benign L2 evidence for acceptance. The public race is designed to panic L0 and can interrupt unrelated tenants. Reproduction belongs on an isolated, disposable research host with explicit scheduling and out-of-band recovery.

4 Rmap insertion and removal select two different GFNs
An rmap starts with a guest frame and finds the SPTEs that map it. Dirty logging, MMU-notifier invalidation, and memslot updates all need that reverse direction. Each rmap entry stores an SPTE address, and the address must remain valid only for the lifetime of its containing shadow page.
4.1 Leaf installation uses the walk; teardown uses the page role
The new leaf inside the wrong direct child comes from an indirect walk. Its installer has resolved the Q GFN named by the guest page table, so it adds the SPTE address to Q's rmap bucket. That key accurately describes the current mapping. Removal later examines the containing kvm_mmu_page, sees a direct role, and reconstructs another GFN.
kvm_mmu_page_get_gfn() at pinned lines 3270–3283 shows the two sources. With shadowed_translation, the function retrieves the translation saved at installation. Without that array, it derives a value from sp->gfn, index, and level. A direct page takes the derived path, which names the consecutive split range, while Q may be any frame.
The remover queries the derived bucket and leaves the real entry in Q's bucket. Pinned lines 3331–3360 also show translation recording and the gfn mismatch under direct page warning. That string is a high-value investigation clue. Distribution configuration, cleanup order, and crash persistence determine whether it survives in a particular incident.

4.2 Memslot teardown carries the stale SPTE beyond the page lifetime
A memslot describes how a guest-physical range is backed by host userspace memory. Deleting, replacing, or reconfiguring one zaps related shadow pages, unlinks parents, and returns pages to the allocator. Normal rmap entries are all removed before the page is freed. Januscape's Q entry still points to an SPTE slot inside the former shadow page.
A later dirty-logging pass or MMU-notifier invalidation walks Q's rmap and dereferences that address as an active SPTE. The old page may now contain an unrelated kernel object, yielding a host use-after-free. Some cleanup orders first reach a consistency assertion in pte_list_remove() or KVM_BUG_ON_DATA_CORRUPTION and panic. Another order lets the stale address survive until page reuse.
The public write-up defines the stronger primitive's limits. Cleanup through an orphaned parent can write SHADOW_NONPRESENT_VALUE to one slot in the reused page. The published x86-64 analysis gives the value as 0x8000000000000000. The attacker influences the slot while the value remains fixed; cross-cache reuse, member alignment, architecture, and allocator behavior determine the consequence. This primitive establishes host-integrity impact. Complete code execution remains the researcher's separately reported evidence layer.
The released demonstrator chooses host panic as a reproducible endpoint and omits the complete heap arrangement. Incident reporting should keep three conclusions distinct: an observed panic and co-resident outage; host UAF and the fixed-value primitive supported by source and public research; and guest-to-host execution reported by the researcher without public reproduction detail. Recovery, patch priority, and attribution consume those layers differently.

5 Complete role.word equality cuts the chain at reuse
Mainline commit 81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb entered on June 19, 2026 with six insertions and four deletions. It places the repair at the first point where both requested identity and stored identity are available. Rmap, memslot teardown, and the allocator need no Januscape-specific recovery path.
5.1 Requested role is constructed before existing-child acceptance
The repaired pinned lines 2459–2472 call kvm_mmu_child_role(sptep, direct, access) at function entry. The reuse condition retains present, non-large, child, and GFN tests and adds child->role.word == role.word. When both identity values match, -EEXIST still serves the hot path. When role differs, the function passes that same requested role to kvm_mmu_get_shadow_page().
The correct indirect page receives the new walk, so leaf insertion and removal both use the preserved translation. Tracking retires the old direct child through its ordinary path, and Q's rmap entry is removed before the page ends. The race interval can still occur; the role-aware decision makes cached-object validation agree with current semantics inside that interval.
Full word comparison covers direct, level, access, quadrant, and the other role fields. The published construction needs only a direct-bit difference, while upstream defines reuse through complete role identity. This also simplifies future audit: the role constructor creates the canonical identity, and the reuse site performs equality without maintaining a scattered list of currently interesting bits.
Source comments and backport notes should retain the downstream asymmetry: a direct page derives GFN from base and index, while an indirect page preserves the walked translation. That explanation tells a future performance refactor that the role check protects rmap lifetime and is larger than one demonstrator's timing.

5.2 Downstream acceptance proves behavioral equivalence
Distribution source can reorganize helpers, structures, and the fetch loop. Review should walk from the fault entry through child selection, leaf installation, rmap removal, and memslot teardown. A textual hit for role.word locates a candidate patch. The required result is that a same-GFN, different-role request refuses the existing child and uses one requested role to acquire the replacement page.
The neighboring unexpected-GFN repair must remain present. The complete acceptance contract requires stored GFN to equal requested GFN and stored role word to equal requested role word. Failure of either condition stops traversal through the old child. An older branch that directly continues on a present linked child in its fetch loop needs coverage on that equivalent shortcut.
Lines 5.10 and 5.15 require additional evidence. The Linux CNA fixed floors omit them, and the upstream 5.10.261 and 5.15.212 ChangeLogs published on July 24, 2026 contain no unexpected-role repair subject or mainline commit. That check defines the public release-record scope. Final acceptance for an enterprise distribution still needs a vendor advisory, source-package diff, or auditable equivalent behavior linked to the package build actually executing.
6 Six fixed lines, one regression matrix, and one host recovery
The Linux CNA floors apply to their corresponding upstream branches. Enterprise kernels often carry fixes in package versions that appear older, so a version string needs vendor-advisory or source-behavior evidence. A package present in a repository, a package installed on disk, and a kernel executing on L0 are three different states. Only the executing state changes the KVM MMU serving tenants.
The historical first-fixed floor and today's deployment target are separate decisions. The kernel.org release list on July 27, 2026 shows current stable or long-term releases at 7.1.5, 6.18.40, 6.12.98, 6.6.145, and 6.1.178; estates that follow kernel.org directly should use those releases or a later supported update. Version 7.2-rc5 is a mainline candidate and carries no production support policy. Enterprise estates should use the vendor's current supported package that explicitly contains equivalent behavior.
6.1 Official fixed floors and commit anchors
| Upstream line | First confirmed fixed release | Stable commit | Acceptance meaning |
|---|---|---|---|
| 6.1.y | 6.1.177 | b1337aae5e19 | Reach this floor or obtain vendor evidence for an equivalent backport |
| 6.6.y | 6.6.144 | 9291654d69e0 | Existing-child reuse compares GFN and complete role |
| 6.12.y | 6.12.95 | 2ad3afa40ac6 | Restart after installation and preserve a new boot ID |
| 6.18.y | 6.18.38 | 5e470998a23e | Bring every migration destination to the same result |
| 7.1.y | 7.1.3 | 1ae7d5a6db6c | Prove the executing build, beyond the repository candidate |
| Mainline | 7.2-rc1 | 81ccda30b4e8 | Use as the behavior reference while following vendor support policy |
Upstream 6.12.94 is below the 6.12.y floor and 6.12.95 reaches it; a vendor package named 5.x may still contain an equivalent repair. The host record should retain full package build, digest and signature, vendor mapping, install time, running uname -r, boot ID, CPU vendor, and KVM modules. Golden images, autoscaling sources, disaster-recovery pools, and powered-off spares belong in the same change.
6.2 The regression matrix observes identity and lifetime directly
| Test cell | Construction or input | Expected repaired behavior | Failure meaning |
|---|---|---|---|
| Normal reuse | same GFN / same complete role | Preserve the existing child and -EEXIST hot path | The backport may rebuild pages on every fault |
| Januscape negative control | same GFN / different role | Reject the direct child and acquire the correct page with requested role | The unexpected-role path remains reachable |
| Neighboring GFN control | different GFN / linked child | Stop traversal through the old child and retire the mismatched link | The 0cb2 unexpected-GFN repair is absent |
| Lifetime | Install leaf, change role, zap, and delete memslot | Insertion and removal use one GFN; the bucket is empty after page teardown | Stale rmap or leaked shadow page |
| Ordinary nested function | Offered VMX/SVM, L2 faults, dirty logging, and migration | Workload completes with no new KVM MMU WARN, BUG, or lockup | Backport or platform compatibility regression |
| Performance | Nested fault latency, allocation, MMU lock, and L2 throughput | Same-role reuse remains; role mismatch pays only the needed acquisition cost | The secure condition was expanded across the hot path |
The matrix turns a probabilistic panic into deterministic invariants. The same-GFN, different-role cell observes rejection of the existing direct child and verifies that the replacement carries the requested role. The lifetime cell continues through memslot teardown and verifies an empty rmap bucket. A debug kernel, targeted selftest, or controlled instrumentation can produce this evidence without giving a production node the public demonstrator's crash endpoint.
Following one canary host makes the production closure concrete. Before maintenance, export host ID, boot ID, CPU vendor, running package, effective and persistent nesting state, resident L1s, every migration destination, and existing KVM errors. Pause new nested scheduling, move L1s to an accepted pool, and handle non-migratable exceptions such as device passthrough. After draining, install the fixed package, reboot, and prove the executing code through the new boot ID, package signature, and source or advisory mapping.
Before the canary rejoins the pool, run the VMX or SVM function that the platform actually offers. Cover L2 start and stop, faults, legitimate huge/table transitions, memslots, dirty logging, and migration, along with the identity and lifetime observations in the matrix. Expand by host pool after logs and performance pass. Restore from L0 to module configuration, control-plane capability, instance flavor, and tenant scheduling in that order. Every destination receives its own acceptance because migration carries no source-host security guarantee.
If the new kernel breaks a driver, migration, or a supported nested workload, the host may boot the previous operational kernel for diagnosis while remaining isolated with nesting disabled. It returns to nested scheduling after a repaired compatible build passes the matrix. At rollout completion, the bootloader default, monitoring, and compliance system should all read the currently executing kernel and alert on an old-kernel boot.

7 Host-panic conclusions must match the strength of the evidence
After a relevant panic, remove the node from scheduling and preserve pstore, kdump, serial or BMC console output, remote logs, the full kernel build, boot ID, KVM modules and parameters, co-resident instances, L1/L2 capability, memslot operations, and migration history. Capacity can recover on fixed hosts while evidence collection continues. The most volatile data must be collected before automated rebuild or pool return.
7.1 Logs, reachability conditions, and observed impact answer different questions
gfn mismatch under direct page, a pte_list_remove BUG, or a nearby KVM MMU stack makes the event a high-value candidate. Version and boot evidence answer whether vulnerable code was executing. Nesting and L1 capability answer who could reach it. A dump and stack answer which path this crash followed. Co-residency and business logs answer the observed outage. Attribution comes from the combination.
When the log window contains no clue, the accurate conclusion is “no related evidence was observed in the available window.” Host panic can interrupt local persistence, pstore or kdump may never have been enabled, and historical records can rotate. The patch closes the future path while leaving past missing telemetry unrecoverable.
If nesting was enabled without a tenant ledger, reconstruct capability from VM configuration, CPUID exposure, device ACLs, service APIs, images, job records, and scheduler history. Mark any remaining interval unknown and make future grants auditable. Preserve the identity and control-plane history of a suspicious L1 before considering experiments; the production host has no need to rerun a crash demonstrator.
An attribution report should use three explicit voices: observed, supported by source and public research, and reported by the researcher. One panic does not carry the complete-escape conclusion. The unpublished escape details also leave the host UAF and cross-tenant availability impact at full remediation priority. Evidence levels let recovery owners, vulnerability managers, and investigators make different decisions from the same facts.
7.2 Closure belongs in scheduling, boot proof, and crash telemetry
Three observable controls keep the result in place. First, nested capability schedules only to hosts whose source behavior, executing build, and ordinary L2 regression all passed. Second, any kernel, image, or module-configuration change recalculates the eligible pool. Third, every KVM MMU panic automatically preserves pstore, kdump, boot ID, and co-resident ownership. The repair outcome then persists in scheduling and incident telemetry.
As of July 27, 2026, the root cause and acceptance invariants in this report remain stable: an existing child's GFN and complete role must both match; leaf rmap insertion and removal must use the same translation; and every entry into an SPTE slot must be removed before its page is freed. Stable branches and vendor versions will continue to move, so deployment should use the currently supported fixed package and bind the vendor claim to the L0 build actually booted.
Januscape leaves one concrete reuse rule. Equal address or ID establishes equal resource location; type, permission, generation, owner, and role decide whether the object can continue. The ten-line KVM change restores that rule. When the same GFN arrives with a new role, the walk obtains the correct shadow page, the rmap ends with that page, and the host no longer pays for a premature reuse with a use-after-free.
Research record
8Evidence, objects, and sources
The material below preserves the identifiers and references used in this report.
8.1Research objects
Products, actors, techniques, affected objects, and control points discussed in the report.
Januscape: KVM/x86 shadow-MMU unexpected-role use-after-free
Nested shadow-paging path shared by Intel VMX and AMD SVM
Old existing-child reuse checked GFN before constructing and comparing complete role
Unexpected-GFN UAF repair; both GFN and role repairs are required
Construct requested role first and require full role.word equality
Correlate with affected kernel, nesting, KVM MMU stack, and guest ownership
Constrained fixed-value write within a reused page
5.10/5.15 estates require vendor evidence for an equivalent backport
8.2Event chronology
- Affected design lineage begins
Commit 2032a93d66fa removes redundant per-entry GFN storage from direct MMU pages.
- Adjacent GFN issue repaired
0cb2af2ea66a closes the unexpected-GFN path; same-GFN/different-role remains.
- Vulnerability reported and patch formed
The researcher reports the unexpected-role UAF; the mainline repair carries this author date.
- Mainline repair merged
81ccda30b4e8 makes existing-child reuse compare both GFN and complete role.
- CVE assigned and stable lines released
CVE-2026-53359 receives its identifier and multiple maintained branches publish fixed versions.
- Januscape disclosed
The technical account and host-panic demonstrator are published after embargo; the complete escape is withheld.
- SOSEC deep-audit rewrite completed
SOSEC integrates pinned source lines, first-screen response, deterministic regression, and L0 production recovery into the bilingual report.
8.3Sources and material
- CVE.org: official CVE-2026-53359 recordhttps://www.cve.org/CVERecord?id=CVE-2026-53359
- NVD: CVE-2026-53359 recordhttps://nvd.nist.gov/vuln/detail/CVE-2026-53359
- Linux vulnerable parent: GFN-only child reuse, lines 2459–2470https://github.com/torvalds/linux/blob/c6f1b611c66f835180e3cb0d3a5df31a61f74d08/arch/x86/kvm/mmu/mmu.c#L2459-L2470
- Linux repair: requested role and complete-role comparison, lines 2459–2472https://github.com/torvalds/linux/blob/81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb/arch/x86/kvm/mmu/mmu.c#L2459-L2472
- Linux pinned source: kvm_mmu_page_get_gfn, lines 3270–3283https://github.com/torvalds/linux/blob/81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb/arch/x86/kvm/mmu/mmu.c#L3270-L3283
- Linux mainline: unexpected-role repair 81ccda30b4e8https://git.kernel.org/stable/c/81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb
- Linux: adjacent unexpected-GFN repair 0cb2af2ea66ahttps://git.kernel.org/stable/c/0cb2af2ea66ad8ff195c156ea690f11216285bdf
- Linux: direct MMU-page GFN-array optimization 2032a93d66fahttps://git.kernel.org/stable/c/2032a93d66fa282ba0f2ea9152eeff9511fa9a96
- Linux 6.1.y stable repair b1337aae5e19https://git.kernel.org/stable/c/b1337aae5e194324e4810d561764e7793f8b3864
- Linux 6.6.y stable repair 9291654d69e0https://git.kernel.org/stable/c/9291654d69e08542de37755cebe4d5b02c3170d1
- Linux 6.12.y stable repair 2ad3afa40ac6https://git.kernel.org/stable/c/2ad3afa40ac6aa340dada122f9abfa46c0a6eb35
- Linux 6.18.y stable repair 5e470998a23ehttps://git.kernel.org/stable/c/5e470998a23e4c3d89ed24e8172cb22747e61efa
- Linux 7.1.y stable repair 1ae7d5a6db6chttps://git.kernel.org/stable/c/1ae7d5a6db6c190ce183e3098ca0e0846e14d462
- Januscape public research and host-panic demonstrator repositoryhttps://github.com/V4bel/Januscape
- Januscape technical write-uphttps://github.com/V4bel/Januscape/blob/main/assets/write-up.md
- oss-security: Januscape disclosurehttps://www.openwall.com/lists/oss-security/2026/07/06/7
- Canonical: Januscape mitigation and estate discoveryhttps://ubuntu.com/blog/januscape-linux-vulnerability-mitigations-available
- kernel.org: current mainline, stable, and long-term releaseshttps://www.kernel.org/releases.json
- kernel.org: Linux 5.10.261 ChangeLoghttps://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.261
- kernel.org: Linux 5.15.212 ChangeLoghttps://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.212
- Google Security Blog: kvmCTF program backgroundhttps://security.googleblog.com/2024/06/virtual-escape-real-reward-introducing.html