Skip to main content

Linux Kernel EUVDEUVD-2026-108933

| CVE-2026-99082 HIGH
2026-10-23 Linux GHSA-58r9-ch9w-px7w
8.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Control KVM guest vCPU in SMM
  2. Delivery
    Fill per-vCPU MMIO cache for SMM address space
  3. Exploit
    Trigger SMM memslot update
  4. Execution
    Valid RAM access returned as KVM_EXIT_MMIO
  5. Persist
    VMM writes backing page outside write-tracking
  6. Impact
    Stale 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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

Linux patch: 7.2.12
Linux patch: 0
Linux 699023e239658e62da6f42f47d31b54788521ec1 <e792a9ace39d2812a5b342a1987186c7bc653204
Linux patch: 7.3
Linux patch: 6.18.58
Linux patch: 6.6.160
Linux patch: 6.12.114
Linux 699023e239658e62da6f42f47d31b54788521ec1 <7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd
Linux 699023e239658e62da6f42f47d31b54788521ec1 <b3e6212dea2e4328a841ceb37f377583176dc735
Linux 699023e239658e62da6f42f47d31b54788521ec1 <a63f79d9da9468952396af73e1e53330845cf876
Linux 699023e239658e62da6f42f47d31b54788521ec1 <2566780c684c9c21241d409d790087c73070f312
Linux 4.2

Affected Packages

euvd linux no fix

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

Vendor (Linux) PRIMARY 8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI 8.8 HIGH

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.

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

4
CVSS changed
Oct 24, 2026 - 14:22 NVD
8.8 (HIGH)
Patch available
Oct 23, 2026 - 14:02 EUVD
CVE Published
Oct 23, 2026 - 12:45 cve.org
UNKNOWN (no severity yet)
CVE Published
Oct 23, 2026 - 12:45 cve.org
HIGH 8.8

DescriptionCVE.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

Why It Matters

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.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 90% exploitable
Prevalence
Ubiquitous
Linux kernel KVM is near-universal, though exploit path needs SMM plus nested virtualization
Data Quality
4 sources
Confidence: Medium

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.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
High

Priority Score

44
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy