Description

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page Explicitly clear role.invalid when deriving a child shadow page's role from its parent to harden against bugs elsewhere in KVM, as violating KVM's invariant that invalid pages are NOT on the list of active MMU pages leads to use-after-free due to __kvm_mmu_prepare_zap_page() using list_add() instead of list_move() when processing an invalid shadow page, i.e. makes a bad situation far worse. Yell loudly if the parent is invalid, as it means KVM has missed a validity check, i.e. KVM is attempting to map memory using an invalid/obsolete root, but continue on as the child is otherwise still a valid shadow page. ================================================================== BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] Write of size 8 at addr ff11000153dd1368 by task repro/853 CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x4b/0x70 print_report+0x153/0x49c kasan_report+0xbc/0xf0 __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] mmu_alloc_root+0x141/0x320 [kvm] kvm_mmu_load+0x612/0x20f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Allocated by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x5f/0x70 kmem_cache_alloc_noprof+0xfe/0x2e0 __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm] paging64_page_fault+0x318/0x1e30 [kvm] kvm_mmu_do_page_fault+0x21d/0x630 [kvm] kvm_mmu_page_fault+0x18c/0x17b0 [kvm] kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free+0xe2/0x400 kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm] kvm_mmu_free_roots+0x283/0x560 [kvm] kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.3",
  "pubDate": "2026-09-03T13:06:11.020Z",
  "pubdate": "2026-09-03T13:06:11.020Z",
  "executiveSummary": "This vulnerability involves a Use-After-Free (UAF) condition within the Linux kernel's KVM (Kernel-based Virtual Machine) subsystem, specifically residing in the MMU (Memory Management Unit) shadow paging logic.\nThe flaw occurs when an invalid shadow page is processed incorrectly, leading to a memory corruption scenario during the lifecycle management of active MMU pages.\nAn attacker capable of triggering specific KVM MMU operations may be able to manipulate the internal state of shadow page tables, resulting in a use-after-free situation.\nThis vulnerability is critical as it could lead to arbitrary code execution within the context of the host kernel, privilege escalation, or system-wide denial-of-service.\nSuccessful exploitation requires the attacker to have sufficient privileges to interact with the KVM interface, typically achieved through a compromised guest or a malicious local user account with access to /dev/kvm.\nThe issue manifests as a violation of the kernel's internal invariants regarding page validity, causing improper list management when zapping pages.",
  "technicalDetails": "The vulnerability originates in the KVM MMU component, specifically within functions related to the creation and lifecycle management of shadow pages, such as __kvm_mmu_get_shadow_page().\nThe core issue is a violation of the KVM invariant: invalid shadow pages must not remain on the list of active MMU pages. When __kvm_mmu_prepare_zap_page() processes a shadow page, it relies on list operations to track memory usage. If a page is marked as invalid but is still processed, the use of list_add() instead of list_move() when handling these pages creates a discrepancy in the management structures.\nThe attack flow initiates when the system attempts to derive a child shadow page's role from a parent page. If the parent page has been marked as 'invalid' due to prior processing or obsolescence, the derivation logic may carry over or fail to clear the role.invalid bit. Because KVM does not explicitly clear this bit during derivation, the system creates a child page that inherits invalid status without proper enforcement.\nSubsequently, if this 'invalid' child page is prematurely freed (e.g., during kvm_mmu_free_roots or commit_zap_page logic) while still being referenced by internal tracking structures, a use-after-free (UAF) condition occurs. The KASAN (Kernel Address Sanitizer) trace explicitly identifies a slab-use-after-free error during the write operation at __kvm_mmu_get_shadow_page().\nThe vulnerability allows for memory corruption because the kernel's reference counting and list management logic become desynchronized. An attacker can influence this by triggering page faults or VCPU ioctls that force the MMU to walk and allocate shadow pages in ways that expose this race or logical error. When the kernel attempts to write to or access the memory associated with the 'freed' shadow page, it interacts with stale memory, which may have been reallocated for other kernel objects.\nThis permits an attacker to potentially corrupt kernel memory structures, bypass guest-host isolation, or overwrite function pointers if they can control the contents of the reallocated slab object. Given that this occurs within the KVM subsystem, the impact is significant, as it provides a pathway for an unprivileged user to escalate privileges or compromise the host machine's kernel stability."
}