16-Year-Old Linux KVM Vulnerability Allows Malicious Guests to Corrupt Host Kernel Memory

A newly disclosed Januscape (CVE-2026-53359), a 16-year-old use-after-free vulnerability in Linux KVM’s shadow MMU that lets a malicious guest corrupt host kernel memory using guest-side actions alone.

The flaw affects the shadow MMU code shared by both Intel VMX and AMD SVM implementations of x86 KVM, making it the first publicly known guest-to-host exploit that can be triggered on both architectures.

The bug lives in kvm_mmu_get_child_sp(), the function that fetches or reuses shadow pages while KVM shadows guest page tables.

16-Year-Old Linux KVM Vulnerability

The flaw was actively exploited as a zero-day in Google’s kvmCTF competition before disclosure, underscoring real-world exploitability against multi-tenant cloud platforms like GCP and AWS that expose nested virtualization to untrusted guests.

The vulnerable reuse check compared only the guest frame number (gfn) of an existing shadow page, ignoring its role, whether it was an indirect page shadowing a guest page table or a direct split page carved from a large page.

When nested virtualization is active, L0 (the host) must shadow L1’s nested EPT/NPT in software, since hardware two-stage paging only supports one level. In this path, KVM’s fetch routine can request a direct split page and an indirect page for the same gfn.

Since the pre-patch code checked gfn alone, it would incorrectly reuse a page from the wrong role, corrupting the rmap (reverse-map) that KVM relies on to track shadow page table entries.

This role confusion breaks lifetime tracking, producing orphaned parent pointers into freed shadow pages. Two outcomes follow:

  • Use-after-free write: clearing an orphaned pointer writes a fixed constant (SHADOW_NONPRESENT_VALUE) into whatever kernel object now occupies that freed memory.
  • Denial-of-service (the public PoC’s path): a gfn mismatch between the rmap’s expected key and the actual lookup key trips KVM’s own KVM_BUG_ON_DATA_CORRUPTION check, triggering an immediate kernel panic under CONFIG_BUG_ON_DATA_CORRUPTION (default on distributions like RHEL).

The published PoC runs as a kernel module inside a guest (L1), which builds its own nested guest (L2) using raw VMX or SVM instructions.

Januscape Flaw (Source: V4bel)
Januscape Flaw (Source: V4bel)

It engineers a memory layout where a single physical page serves simultaneously as a large-page leaf and a page-table page, then races two vCPU threads: one toggling a page directory entry between “huge” and “table” states.

V4bel stated that others repeatedly fault in L2 to hit the narrow non-atomic window during host emulation of that toggle. Winning the race triggers the role-confused reuse, ultimately panicking L0.

Because the vulnerable code sits in architecture-shared arch/x86/kvm/mmu/mmu.cThe same logic drives both Intel and AMD backends via a small abstraction layer that swaps page-table bit encodings.

A full privilege-escalation exploit chaining the same bug into host code execution reportedly exists but hasn’t been released, given the difficulty of aligning the fixed corruption write with an exploitable kernel object.

Researchers reported Januscape to security@kernel.org on June 12, 2026. KVM maintainers Paolo Bonzini and Sean Christopherson developed a patch, merged into mainline as commit 81ccda30b4e8 on June 19. CVE-2026-53359 was assigned July 4, and the embargo was lifted July 6.

The fix adds a role.word comparison alongside the gfn check in kvm_mmu_get_child_sp(), ensuring shadow pages are only reused when both gfn and role match closing the role-confusion window entirely.

Follow us on Google News , LinkedIn and X to Get More Instant UpdatesSet Cyberpress as a Preferred Source in Google.

Tamilselvan
Tamilselvanhttps://cyberpress.org/
Tamilselvan is an Investigative cybersecurity journalist dedicated to breaking stories on ransomware cartels, data breaches, and state-sponsored espionage.

Trending News

Related Stories