CVE-2026-46113

What it actually does

This is a use-after-free flaw in the Linux kernel KVM x86 shadow MMU. Under specific shadow paging conditions, KVM can create reverse-map metadata for a guest frame number that does not match the range associated with an existing shadow page. When the related memory slot is later removed or invalidated, KVM may fail to remove the stale reverse-map entry. A subsequent reverse-map walk, such as during dirty logging or MMU notifier invalidation, can dereference a freed kvm_mmu_page. The result can be host kernel memory corruption, host crash, or potentially arbitrary code execution in the host kernel context. The issue is most relevant to KVM-based virtualization on x86 systems using shadow paging or falling back to shadow MMU behavior rather than normal hardware-assisted nested paging.

Why it matters to the business

Successful exploitation could allow a malicious or compromised virtual machine workload to destabilize or potentially compromise the virtualization host, affecting the confidentiality, integrity, and availability of other workloads on the same host. In practical terms, this may cause host crashes, VM outages, failed migrations or memory-management operations, and possible cross-tenant or cross-workload risk in environments that run untrusted guests. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the high CVSS score reflects the severity if an attacker can reach the vulnerable KVM execution path.

How an attack unfolds

An attacker first needs the ability to execute code in, or otherwise control memory-management behavior of, a guest VM running on an affected Linux KVM x86 host. The attacker manipulates guest paging state so KVM creates a direct shadow page for a large mapping, then changes the relevant guest page-table mapping so a later access in the same region is associated with a different guest frame number than KVM originally assumed. KVM may then install a shadow page-table entry and reverse-map entry in the wrong relationship to the shadow page. When host-side VM memory management later deletes or invalidates the relevant memory slot, or when dirty logging, migration, ballooning, MADV_DONTNEED, or MMU notifier activity causes KVM to walk reverse maps, KVM can follow a stale reverse-map entry and dereference a freed kvm_mmu_page. The immediate visible outcome is likely a host kernel oops, panic, KASAN warning, or VM/host instability; with sufficient heap shaping, the memory corruption primitive may be usable for host kernel privilege escalation or escape from guest isolation.

How to fix it

Apply the vendor-provided Linux kernel update that contains the KVM x86 MMU fix for this vulnerability, then reboot affected hosts so the patched kernel is running. No exact fixed package versions were provided in the input, so use distribution-specific advisories for the applicable kernel stream and verify that the KVM x86 shadow MMU fix is included. Prioritize hypervisors and hosts running untrusted or multi-tenant VMs. Where patching is not immediately possible, reduce exposure by avoiding configurations that force KVM shadow paging, ensuring hardware-assisted nested paging is enabled where available, disabling or limiting nested virtualization for untrusted workloads, restricting who can launch or control VMs, and moving high-risk or untrusted guests away from unpatched hosts. Operational mitigations should not be treated as equivalent to patching because normal VM lifecycle operations such as migration, dirty logging, memory reclamation, or invalidation can help trigger the vulnerable path.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is updated to a vendor build containing the KVM x86 shadow MMU fix. Reboot and check the active kernel with standard OS tooling such as uname and the distribution package manager. Validate whether KVM is present and in use by checking loaded kvm, kvm_intel, or kvm_amd modules and hypervisor processes such as QEMU/KVM. Review vendor advisories or kernel changelogs for wording related to fixing KVM x86 shadow paging use-after-free, unexpected GFN mismatch, stale rmap entries, or zapping an existing SPTE on target GFN mismatch. If mitigation rather than patching is used, verify hardware nested paging is enabled and that untrusted guests are not running on hosts that can fall back to shadow paging. After patching, monitor for absence of recurring host kernel oops, KASAN, or panic events referencing KVM MMU reverse-map handling during VM memory operations.

Typical attack path

1. Gain the ability to run controlled code inside a VM on an affected Linux KVM x86 host.
2. Ensure the VM exercises KVM shadow paging or a configuration where the shadow MMU path is used.
3. Create guest page-table activity involving a large mapping that causes KVM to build a direct shadow page covering a 2 MB range.
4. Modify the guest mapping so a later access in that range resolves to a guest frame number outside the shadow page's originally assumed range.
5. Trigger KVM to install or retain inconsistent SPTE and reverse-map metadata.
6. Cause or wait for host-side memory-slot deletion, memory invalidation, dirty logging, migration, ballooning, or MMU notifier activity.
7. KVM walks a stale reverse-map entry and dereferences a freed kvm_mmu_page.
8. Use the resulting condition to crash the host or attempt controlled kernel memory corruption for privilege escalation or VM escape.

How to detect it

Post-compromise detection should focus on host-level evidence, because exploitation occurs in the KVM kernel path and may not create guest-visible artifacts. Review persistent kernel logs, system journal, crash dumps, hypervisor logs, and VM lifecycle audit logs for kernel oops, panic, KASAN, KFENCE, slab, or general protection fault reports involving KVM x86 MMU code, reverse-map walks, shadow page handling, dirty logging, MMU notifier invalidation, or memory-slot deletion. Correlate suspicious crashes or warnings with VM operations such as live migration, enabling dirty logging, memory ballooning, memory hot-unplug, MADV_DONTNEED-backed memory reclamation, VM reset, or QEMU/KVM process termination. Look for repeated host instability triggered by the same guest or shortly after intensive guest page-table activity. A clean log does not prove non-exploitation: a successful kernel-level exploit may suppress obvious crash artifacts, and an unsuccessful attempt may appear only as a generic host kernel fault.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• KFENCE: use-after-free
• general protection fault
• kernel BUG at arch/x86/kvm/mmu
• Oops:
• RIP: kvm_mmu
• RIP: rmap_remove
• RIP: rmap_walk
• RIP: kvm_mmu_page
• RIP: mmu_notifier
• kvm_mmu_page
• rmap_remove
• rmap_walk
• spte
• SPTE
• shadow page
• shadow MMU
• unexpected GFN
• gfn mismatch
• kvm_mmu_zap
• kvm_zap
• kvm_mmu_prepare_zap_page
• kvm_mmu_invalidate
• kvm_set_memory_region
• KVM_SET_USER_MEMORY_REGION
• dirty logging
• KVM_GET_DIRTY_LOG
• MADV_DONTNEED
• qemu-system-x86_64
• kvm_intel
• kvm_amd

What your security team should do

• Inventory Linux KVM x86 hosts and identify systems running untrusted, multi-tenant, or externally supplied VM workloads.
• Prioritize kernel patching and reboot of affected virtualization hosts despite the currently low EPSS score, because exploitation impacts the host kernel and guest isolation boundary.
• Check whether any hosts are configured to use, or can fall back to, KVM shadow paging; treat those hosts as higher risk.
• Temporarily isolate or migrate untrusted VMs away from unpatched hosts where operationally feasible.
• Restrict VM creation, nested virtualization, live migration, memory hotplug, and administrative VM controls to trusted users until patching is complete.
• Review host logs for KVM MMU-related crashes, KASAN use-after-free reports, rmap warnings, unexpected QEMU/KVM terminations, or host reboots around VM memory-management events.
• Ensure crash dump collection, persistent kernel logging, and hypervisor audit logging are enabled on KVM hosts before large-scale remediation or workload migration.
• After patching, run validation checks to confirm the active running kernel contains the fix and that all affected hosts were rebooted.