CVE-2026-53359

What it actually does

This is a Linux kernel KVM x86 shadow paging use-after-free. Under a specific sequence involving guest page-table changes, reuse of a shadow MMU page with an unexpected role, and deletion of a KVM memory slot, KVM can leave a stale reverse-map entry pointing into a freed shadow page. Later KVM MMU activity, such as dirty logging or MMU notifier invalidation, can dereference the freed shadow page table entry. The most likely technical outcome is a host kernel crash or memory corruption in the KVM subsystem; depending on kernel hardening, timing, and allocator behavior, use-after-free bugs in this area may also present a path toward host privilege escalation or VM isolation escape.

Why it matters to the business

Organizations running x86 virtualization on affected Linux kernels could experience instability of virtualization hosts, denial of service for hosted workloads, or a potential compromise of the host from a malicious or compromised virtual machine workload. The current EPSS value is low and this is not listed in CISA KEV, but the issue affects a privileged kernel component that enforces VM isolation, so cloud, hosting, CI/CD, sandboxing, and multi-tenant virtualization platforms should treat it as higher priority than a typical local kernel bug. The provided threat-actor context names Januscape, but no mature public exploit is indicated in the supplied data.

How an attack unfolds

An attacker first needs a path to run or influence a KVM virtual machine on an affected x86 Linux host, and exploitation appears to require a precise interaction between guest memory translations and host-side KVM memory-slot changes. The attacker manipulates guest page-table mappings so that a page-directory entry changes from a large-page mapping to a path that causes KVM to reuse an existing shadow MMU page with a mismatched role. KVM then installs a new leaf shadow page-table entry and records a reverse-map entry under one guest frame number. When the associated child shadow page is later zapped, KVM computes the guest frame number incorrectly because the parent shadow page has the wrong role, so the reverse-map entry is not removed. If the memory slot is subsequently deleted, the backing shadow page is freed while the stale reverse-map entry remains. Later KVM operations that walk that reverse map, such as dirty logging or MMU invalidation, dereference memory from the freed page, causing a use-after-free condition that can crash the host kernel or potentially be developed into a stronger memory-corruption exploit.

How to fix it

Update affected Linux kernels to a build that includes the upstream KVM x86 fix for the shadow paging role mismatch/use-after-free. No exact fixed package versions were supplied, so use the fixed kernel versions provided by the relevant Linux distribution, cloud image vendor, hypervisor appliance vendor, or long-term kernel maintainer. Prioritize virtualization hosts that run untrusted, multi-tenant, internet-facing, CI, sandbox, or customer-controlled workloads. If immediate patching is not possible, reduce exposure by limiting the ability of untrusted users to create or control KVM guests, avoiding unnecessary memory hotplug or dynamic memslot churn for untrusted VMs, disabling or constraining features that rely on KVM shadow paging where operationally feasible, and applying kernel hardening and live-migration maintenance controls to reduce blast radius. Rebooting into the patched kernel is required unless the vendor explicitly provides and validates a live patch for the affected KVM code path.

How to confirm the fix worked

Confirm the running kernel version on virtualization hosts matches a vendor advisory or kernel build that contains the KVM x86 fix, not merely that the package is installed. Verify after reboot with the active kernel release and package metadata. Review vendor changelogs for references to KVM x86 shadow paging, role mismatch, rmap cleanup, stale rmap entries, or use-after-free in shadow paging. In test environments, run KVM regression tests or vendor-provided kernel validation covering x86 MMU shadow paging, memory-slot deletion, dirty logging, memory hotplug, migration, and MMU notifier paths. Confirm that unpatched kernels are no longer booted by hypervisor hosts, golden images, autoscaling templates, and recovery images.

Typical attack path

1. Obtain the ability to run a VM, control a guest workload, or influence a VM managed by KVM on an affected x86 Linux host.
2. Trigger guest page-table activity that changes a mapping from a large-page style path to a 4 KB page-table path while KVM shadow paging is active.
3. Cause KVM to reuse a shadow MMU page whose role does not match the newly required translation path.
4. Induce installation of a leaf shadow page-table entry that records a reverse-map entry under the new walk-derived guest frame number.
5. Trigger removal or deletion of the relevant KVM memory slot through VM lifecycle, memory hotplug, device assignment, migration, or management-layer behavior.
6. Wait for subsequent KVM MMU activity, such as dirty logging or MMU notifier invalidation, to walk the stale reverse-map entry.
7. Cause the host kernel to dereference a freed shadow page-table entry, resulting in host crash or memory corruption.

How to detect it

There is no single reliable network indicator for this vulnerability because exploitation occurs inside the Linux kernel KVM MMU path. Detection should focus on host-level telemetry from virtualization servers: kernel logs, system journal, hypervisor management logs, VM lifecycle events, crash dumps, pstore records, kdump/vmcore artifacts, and audit logs showing VM memory-slot changes, memory hotplug, migration, dirty logging, or unusual VM start/stop activity around the time of a crash. Look for kernel warnings or crashes involving KVM x86 MMU functions, stale reverse-map handling, shadow paging, use-after-free, page faults, general protection faults, or KASAN/KFENCE reports. Correlate such events with activity by untrusted guests or accounts that manage VMs. If Januscape-related activity is part of the threat model, review broader intrusion telemetry for the same time window, but confirm exploitation through host kernel artifacts rather than actor attribution alone.

• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• use-after-free in kvm_mmu_page_get_gfn
• kvm_mmu_page_get_gfn
• rmap_remove
• kvm_mmu_get_child_sp
• shadow paging use-after-free
• KVM: x86
• general protection fault
• kernel BUG at arch/x86/kvm/mmu
• arch/x86/kvm/mmu
• dirty logging
• MMU notifier invalidation
• stale rmap

What your security team should do

• Inventory all Linux x86 systems acting as KVM hypervisors, including cloud images, virtualization clusters, CI runners, sandbox hosts, and appliance-based deployments.
• Prioritize patching hosts that run untrusted or multi-tenant VMs, because the vulnerable component is part of the VM isolation boundary.
• Track vendor kernel advisories and apply the first stable or distribution-supported kernel containing the KVM x86 shadow paging fix; reboot into the fixed kernel or use a vendor-validated live patch.
• Until patched, restrict who can create, start, migrate, hotplug memory for, or otherwise manage KVM guests on affected hosts.
• Increase monitoring for KVM-related kernel crashes, KASAN reports, general protection faults, and host reboots following VM lifecycle or memory-management operations.
• If unexplained KVM host crashes occurred after publication, preserve kernel logs, crash dumps, VM lifecycle audit logs, and hypervisor management logs for forensic review.
• Treat the named threat-actor context as a reason to monitor closely, but do not assume exploitation without corroborating host-level crash or memory-corruption evidence.