Linux kernel (arch/x86/kvm/mmu): Shadow-page lookup reuses a page without comparing its role, so a direct (2MB) shadow

Impact

Shadow-page lookup reuses a page without comparing its role, so a direct (2MB) shadow page gets reused for a 4KB indirect mapping. The rmap entry recorded under the walked GFN is never removed when the page is zapped, and after the memslot is dropped the freed shadow page is still reachable through that stale rmap. Any later rmap walk - dirty logging, MMU notifier invalidation - dereferences freed host kernel memory.

Who can reach it

Needs the shadow MMU plus a writer that KVM's write tracking does not see: the guest's PDE is changed from outside the guest and then a memslot is deleted. In practice that means a process holding /dev/kvm acting as its own VMM - a tenant with nested virtualization enabled, or any local user with /dev/kvm - not a container tenant with no KVM access. The MMU-notifier trigger (e.g. MADV_DONTNEED, host memory reclaim) then fires on its own.

What to do

Update to a kernel with the referenced stable commits; take it together with CVE-2026-46113, which is the first half of the same hole. Interim: do not hand /dev/kvm to tenants and disable nested virtualization on unpatched nodes.

References