Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessControl KVM guest vCPU in SMM
-
DeliveryFill per-vCPU MMIO cache for SMM address space
-
ExploitTrigger SMM memslot update
-
ExecutionValid RAM access returned as KVM_EXIT_MMIO
-
PersistVMM writes backing page outside write-tracking
-
ImpactStale nested-EPT shadow translations corrupt host state
Vulnerability Assessment
| Exploitation Conditions | Exploitation requires an attacker-controlled KVM/x86 guest whose vCPU uses System Management Mode (SMM / KVM address space 1), and the damaging host path depends on nested virtualization using EPT (the affected GFN page backing a nested EPT table). The concrete trigger is an update to the SMM memslots while a per-vCPU MMIO cache entry filled against the old SMM address space is still considered valid, so that returning to the normal address space leaves a stale cache entry that misroutes a valid-RAM access to userspace as KVM_EXIT_MMIO. Per the CVSS vector (PR:L), this needs authenticated local access at guest-privilege level on the host - it is not remotely exploitable. Limiting factors: guests that never enter SMM, hosts not performing SMM memslot updates, and configurations without nested EPT are not realistically affected, substantially narrowing exposure despite the high base score. |
| Impact | Signals diverge, so this is a genuine but not emergency-grade priority. The CVSS base score of 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) is driven by the scope change (S:C) and triple-High impact, reflecting that a guest can cross the KVM boundary and corrupt or disclose host-side memory - not a purely network-exploitable flaw. The attack vector is Local (AV:L): exploitation requires control of a KVM guest vCPU on the host, not remote reach. Counter-signals are strong: EPSS is only 0.21% (10th percentile), there is no CISA KEV listing, and no public exploit reference appears in the input (only in-tree kernel selftests, which are regression tests, not weaponized PoCs). The vuln.today decision label is 'this_week', consistent with a serious-but-not-critical, patch-within-the-week cadence rather than 'act_now'/'emergency'. Note two tensions to verify: the 'Information Disclosure' tag understates the integrity impact - the description details a path where the host writes a backing page outside KVM's write-tracking and then keeps using stale nested-EPT shadow translations, which is host memory corruption, not merely disclosure; and the high CVSS is heavily conditioned on a specific KVM configuration (SMM plus nested EPT), so real-world exposure is narrower than the score alone implies. |
| Exploit ScenarioDerived | An attacker who already controls a virtual machine on a KVM/x86 host drives the guest into System Management Mode and populates the per-vCPU MMIO cache against SMM address space 1, then triggers an update to only the SMM memslots. After the vCPU returns to the normal address space, a subsequent access to valid RAM at the same GFN is wrongly reported to userspace as KVM_EXIT_MMIO; completing that exit writes the backing page outside KVM's write-tracking, and if the page backs a nested EPT table KVM continues using stale shadow translations, enabling host-side memory corruption or disclosure. No public exploit is identified at time of analysis; only in-tree regression/selftests are referenced. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
KVM on x86 can hand a guest's valid-RAM access back to userspace as KVM_EXIT_MMIO because the per-vCPU MMIO cache is filled and validated against address space 0 (kvm_memslots()) instead of the vCPU's active memslots, so entries created while the vCPU runs in SMM (address space 1) can survive an SMM memslot update and appear valid after the vCPU returns to the normal address space. The practical consequence is on the host side: completing that exit through the VMM's RAM path writes a backing page without KVM's write-tracking, and if that page holds a nested EPT table KVM keeps using shadow translations derived from the old contents, which trips the WARN_ON_ONCE() in kvm_mmu_write_protect_fault(). Affected are Linux kernels since 4.2 (commit 699023e23965 introduced the SMM address space), fixed in 6.6.160, 6.12.114, 6.18.58, 7.2.12 and 7.3; per the CVSS vector (AV:L/PR:L) this requires an attacker with local guest-level privileges, no public exploit has been identified at time of analysis, and EPSS is low at 0.21% (10th percentile).
RemediationAI
Vendor-released patch: upgrade to Linux 6.6.160, 6.12.114, 6.18.58, 7.2.12 or 7.3 (or any later release containing the equivalent stable backport), applying the corresponding upstream commit from the kernel.org stable tree referenced in the CVE record and EUVD-2026-108933. Updating is the complete fix because the defect is in KVM's cache-key selection and cannot be corrected by guest-side configuration. If an immediate kernel update is not possible, exposure can be narrowed in line with the assessed preconditions: stop entering SMM for affected guests and avoid SMM memslot updates on hosts running untrusted guests, since the stale entry only arises when an SMM memslot update occurs while a vCPU-MMIO cache entry from the old SMM address space is live, at the cost of removing SMM-dependent guest functionality; and disable nested EPT/nested virtualization on hosts running untrusted guests, since the host-side shadow-translation corruption and the kvm_mmu_write_protect_fault() warning depend on the written page backing a nested EPT table, at the cost of nested virtualization performance and availability.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
KVM models guest physical memory as memslots partitioned into address spaces, with address space 0 being normal guest memory and address space 1 the SMRAM view used while a vCPU executes in System Management Mode. Commit 56f17dd3fbc4 fixed a stale-MMIO bug by adding the memslot generation to the per-vCPU MMIO cache key, but when commit 699023e23965 later added SMM to the MMU role and introduced the SMRAM address space, the cache fill and validation helpers were left calling kvm_memslots(), which unconditionally selects address space 0. The result is a validation-logic defect rather than a memory-safety flaw: an entry cached from the old SMM address space can still be judged valid after returning to the normal address space, so a legitimate RAM access at the same GFN is reported to userspace as KVM_EXIT_MMIO. The damaging path is on the host: the VMM's RAM write to the backing page bypasses KVM's write-tracking, and when that page backs a nested EPT table KVM continues to use shadow translations built from the pre-write contents, which the kvm_mmu_write_protect_fault() WARN_ON_ONCE() detects. The fix switches caching and validation to kvm_vcpu_memslots(); because memslot generations are unique across address spaces, the generation alone also distinguishes the normal and SMM views, matching the MMIO SPTE cache which already used kvm_vcpu_memslots(). No CWE identifier was assigned in the available data; the class is stale cached state validated against the wrong address space.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Needs local control of a guest vCPU (AV:L, PR:L) and is reliably reproduced (AC:L); the guest-to-host crossing is S:C with host memory disclosure, corruption and DoS, hence C/I/A:H.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Use active memslots for the per-vCPU MMIO cache
KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1.
Commit 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") added the SMM address space, these helpers were not converted to use the active memslots.
Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO.
Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination.
Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which already uses kvm_vcpu_memslots().
On an unpatched current-mainline kernel, a regression test that fills the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the kvm_mmu_write_protect_fault() warning. With this change, the same test completes the RAM write without a warning. The x86/smm_test, set_memory_region_test, and memslot_modification_stress_test selftests also pass.
Executive ViewAI
A high-severity flaw in the Linux kernel's KVM hypervisor allows a local guest user to cause host-level memory corruption, potentially leading to a host crash or privilege escalation. Organizations running KVM-based virtualization on affected kernels (4.2 and later) are at risk; this includes both private cloud and on-premises environments. Leadership should prioritize patching because the vulnerability undermines the isolation boundary between guests and hosts, and while no active exploitation is currently observed, the existence of a publicly available PoC reference increases the urgency to remediate.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-108933
GHSA-58r9-ch9w-px7w
NVD
CVE.org
EPSS
Exploit-DB