CVE-2026-46113

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Fix shadow paging use-after-free due to unexpected GFN<br /> <br /> The shadow MMU computes GFNs for direct shadow pages using sp-&gt;gfn plus<br /> the SPTE index. This assumption breaks for shadow paging if the guest<br /> page tables are modified between VM entries (similar to commit<br /> aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even<br /> when creating an MMIO SPTE", 2026-03-27). The flow is as follows:<br /> <br /> - a PDE is installed for a 2MB mapping, and a page in that area is<br /> accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages;<br /> the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because<br /> the guest&amp;#39;s mapping is a huge page (and thus contiguous).<br /> <br /> - the PDE mapping is changed from outside the guest.<br /> <br /> - the guest accesses another page in the same 2MB area. KVM installs<br /> a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN<br /> (i.e. based on the new mapping, as changed in the previous step) but<br /> that GFN is outside of the [sp-&gt;gfn, sp-&gt;gfn + 511] range; therefore<br /> the rmap entry cannot be found and removed when the kvm_mmu_page<br /> is zapped.<br /> <br /> - the memslot that covers the first 2MB mapping is deleted, and the<br /> kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove()<br /> only looks at the [sp-&gt;gfn, sp-&gt;gfn + 511] range established in step 1,<br /> and fails to find the rmap entry that was recorded by step 3.<br /> <br /> - any operation that causes an rmap walk for the same page accessed<br /> by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page.<br /> This includes dirty logging or MMU notifier invalidations (e.g., from<br /> MADV_DONTNEED).<br /> <br /> The underlying issue is that KVM&amp;#39;s walking of shadow PTEs assumes that<br /> if a SPTE is present when KVM wants to install a non-leaf SPTE, then the<br /> existing kvm_mmu_page must be for the correct gfn. Because the only way<br /> for the gfn to be wrong is if KVM messed up and failed to zap a SPTE...<br /> which shouldn&amp;#39;t happen, but *actually* only happens in response to a<br /> guest write.<br /> <br /> That bug dates back literally forever, as even the first version of KVM<br /> assumes that the GFN matches and walks into the "wrong" shadow page.<br /> However, that was only an imprecision until 2032a93d66fa ("KVM: MMU:<br /> Don&amp;#39;t allocate gfns page for direct mmu pages") came along.<br /> <br /> Fix it by checking for a target gfn mismatch and zapping the existing<br /> SPTE. That way the old SP and rmap entries are gone, KVM installs<br /> the rmap in the right location, and everyone is happy.