Linux kernel (arch/x86/kvm/mmu): The shadow MMU derives GFNs for direct shadow pages arithmetically, which breaks if

Impact

The shadow MMU derives GFNs for direct shadow pages arithmetically, which breaks if the guest page tables change behind KVM's back. A leaf SPTE and rmap entry then land outside the range the parent shadow page covers, survive the zap, and are walked after the shadow page is freed. Dirty logging or an MMU-notifier invalidation then dereferences a freed kvm_mmu_page - host kernel use-after-free.

Who can reach it

Same reachability as its follow-up CVE-2026-53359: shadow paging in use, the PDE modified from outside the guest, and a memslot deletion. That is a process holding /dev/kvm behaving as its own VMM - a tenant with nested virt, or a local unprivileged user with /dev/kvm - after which normal host memory reclaim (MADV_DONTNEED, THP, swap) triggers the stale rmap walk without further attacker action.

What to do

Update to a kernel with the referenced stable commits, alongside CVE-2026-53359. Interim: remove /dev/kvm from tenant containers and disable nested virtualization on unpatched nodes.

References