cbcvebase.
CVE-2026-46113
published 2026-05-28

CVE-2026-46113: In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes…

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

Affected

8 ranges
VendorProductVersion rangeFixed in
linuxlinux——
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < e9d4ea13aa2b6400bb10ec64b370ba3dadcd22f0e9d4ea13aa2b6400bb10ec64b370ba3dadcd22f0
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 488e386484ec8c0e558be6e156edf34ed9f4d5c8488e386484ec8c0e558be6e156edf34ed9f4d5c8
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 06c19c967b845b63172601fe459667d973b7e6b706c19c967b845b63172601fe459667d973b7e6b7
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 738ec97b1855df6c08fe2369f798fa0b972e556b738ec97b1855df6c08fe2369f798fa0b972e556b
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 14d1e55dfd2cf4711bff164a6aaaddb78355213414d1e55dfd2cf4711bff164a6aaaddb783552134
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 0cb2af2ea66ad8ff195c156ea690f11216285bdf0cb2af2ea66ad8ff195c156ea690f11216285bdf
linuxlinux_kernel——