Description
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 write.

That bug dates back literally forever, as even the first version of KVM
assumes that the GFN matches and walks into the "wrong" shadow page.
However, that was only an imprecision until 2032a93d66fa ("KVM: MMU:
Don't allocate gfns page for direct mmu pages") came along.

Fix it by checking for a target gfn mismatch and zapping the existing
SPTE. That way the old SP and rmap entries are gone, KVM installs
the rmap in the right location, and everyone is happy.
Published: 2026-05-28
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A use‑after‑free flaw in the KVM shadow MMU for x86 occurs when a guest modifies its page tables between VM entries. The kernel incorrectly assumes the guest frame number (GFN) of a shadow page remains constant, leading to a stale reverse mapping (rmap). When this rmap is later traversed, it dereferences a freed kvm_mmu_page, corrupting kernel memory and potentially enabling arbitrary host‑level code execution. The issue aligns with CWE‑825, where uninitialized or incorrectly deallocated memory is accessed, threatening confidentiality, integrity, and availability of the host system.

Affected Systems

The vulnerability is present in all Linux kernel releases for x86 that include the legacy KVM shadow paging logic, specifically before the fix commit 06c19c967b845b63172601fe459667d973b7e6b7. It affects standard KVM deployments on Linux hosts where guests can access and modify their own page tables, as the flaw depends on guest‑initiated page table changes.

Risk and Exploitability

The CVSS score of 8.8 indicates high severity, while an EPSS score of less than 1% still points to a low probability of exploitation in the wild. The flaw is not listed in CISA’s KEV catalog. The likely attack vector is a privileged guest that can manipulate its own page tables—a scenario that is common in many virtualized environments. While the presence of the use‑after‑free condition elevates the risk to potential host code execution, the low EPSS reflects limited known exploitation efforts. Nevertheless, the integrity risk inherent in dangling pointers and stale shadow pages warrants timely remediation.

Generated by OpenCVE AI on May 30, 2026 at 13:04 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the kernel patch that updates the KVM shadow paging logic (commits 06c19c967b845b63172601fe459667d973b7e6b7), which removes the use‑after‑free (CWE‑825) vector.
  • If an immediate kernel upgrade is not possible, restrict the guest’s ability to alter its page tables—for example, disable dynamic memory hotplug or block unprivileged memory mapping capabilities—to reduce the chance of triggering the stale rmap walk (mitigating both CWE‑825).
  • Enable kernel debugging and audit logs to flag rmap traversal errors or kernel panics, providing early warning of potential exploitation attempts.

Generated by OpenCVE AI on May 30, 2026 at 13:04 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 01 Jun 2026 17:00:00 +0000


Sat, 30 May 2026 11:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 8.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H'}


Fri, 29 May 2026 04:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Fri, 29 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Thu, 28 May 2026 12:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Thu, 28 May 2026 10:15:00 +0000

Type Values Removed Values Added
Description 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 write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.
Title KVM: x86: Fix shadow paging use-after-free due to unexpected GFN
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-14T17:55:24.179Z

Reserved: 2026-05-13T15:03:33.098Z

Link: CVE-2026-46113

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-28T10:16:26.760

Modified: 2026-06-01T17:17:24.820

Link: CVE-2026-46113

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-28T00:00:00Z

Links: CVE-2026-46113 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-30T13:15:24Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference