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…

PriorityP344high8.8CVSS 3.1
AVLACLPRLUINSCCHIHAH
EPSS
0.15%
5.1th percentile
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

42 ranges· showing 25
VendorProductVersion rangeFixed in
linuxlinux
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < e9d4ea13aa2b6400bb10ec64b370ba3dadcd22f0e9d4ea13aa2b6400bb10ec64b370ba3dadcd22f0
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 488e386484ec8c0e558be6e156edf34ed9f4d5c8488e386484ec8c0e558be6e156edf34ed9f4d5c8
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 06c19c967b845b63172601fe459667d973b7e6b706c19c967b845b63172601fe459667d973b7e6b7
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 738ec97b1855df6c08fe2369f798fa0b972e556b738ec97b1855df6c08fe2369f798fa0b972e556b
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 14d1e55dfd2cf4711bff164a6aaaddb78355213414d1e55dfd2cf4711bff164a6aaaddb783552134
linuxlinux>= 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 < 0cb2af2ea66ad8ff195c156ea690f11216285bdf0cb2af2ea66ad8ff195c156ea690f11216285bdf
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 2.6.20 < 6.1.1756.1.175
linuxlinux_kernel>= 6.13 < 6.18.306.18.30
linuxlinux_kernel>= 6.19 < 7.0.77.0.7
linuxlinux_kernel>= 6.2 < 6.6.1406.6.140
linuxlinux_kernel>= 6.7 < 6.12.886.12.88
ubuntulinux
ubuntulinux-aws
ubuntulinux-azure
ubuntulinux-azure-6.8
ubuntulinux-azure-fde
ubuntulinux-azure-fde-6.8
ubuntulinux-azure-fips
ubuntulinux-fips
ubuntulinux-gcp
ubuntulinux-gcp-6.8

CVSS provenance

nvdv3.18.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vendor_ubuntu7.0HIGH
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.