Skip to main content

Linux Kernel CVE-2026-89930

| EUVDEUVD-2026-80530 CRITICAL
2026-09-16 Linux GHSA-j569-2qg3-pw8x
Denial Of Service Information Disclosure Linux KVM
Critical
Disputed · 9.3 Vendor: Linux
View

Attack ChainAIDerived

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

  1. Access
    Gain code execution in L1 hypervisor guest
  2. Delivery
    Enable/use nested VMX with L2 VPID
  3. Exploit
    Change L2 VPID then force failed VM-Enter
  4. Execution
    Perform successful VM-Enter reusing stale TLB
  5. Impact
    Wrong translations corrupt guest isolation/availability

Vulnerability Assessment

Exploitation Conditions

Requires an Intel VMX host with KVM nested virtualization enabled (nested=1 / L1 running its own hypervisor with L2 guests using VPID). The attacker must already control an L1 hypervisor guest vCPU and drive a specific ordering: reassign L2's VPID, cause a nested VM-Enter to fail (e.g. via failed VMCS checks or MSR-load-list conditions), then issue a subsequent successful VM-Enter so the missed TLB flush leaves stale translations active. Limiting factors: not remotely reachable (local hypervisor context only), requires the non-default nested-virtualization configuration, requires guest-level privilege to manage nested VMCS state, and depends on a precise event ordering rather than a single deterministic request. Not exploitable against default (non-nested) KVM deployments.
Impact

This is a Linux kernel KVM nested-VMX (nVMX) correctness bug: KVM services queued local TLB flushes on full nested VM-Exits but not when a nested VM-Enter fails (e.g. failed VMCS checks in nested_vmx_enter_non_root_mode()). Because nested_vmx_transition_tlb_flush() still updates last_vpid on the failed entry, a sequence of L1 changing L2's VPID → failed VM-Enter → successful VM-Enter can leave stale TLB entries active, producing wrong translations across the L1/L2 boundary. The vendor CVSS of 9.3 (AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) substantially overstates real-world risk. PR:N is inconsistent with the mechanism - triggering this requires executing as an L1 hypervisor guest driving nested VM entries, which is a privileged guest vCPU context (PR:L), and AC:L understates the required race/ordering (specific VPID-change-then-failed-then-successful-entry sequence, AC:H). The impact is a stale-TLB isolation break, which is fundamentally a correctness/DoS and at most weak-integrity issue, not full C:H/I:H/A:H. My independent estimate is ~6.x. There is NO CISA KEV listing, NO public POC, and NO EPSS score provided, so there are no signals of active or imminent exploitation - this reads as a defensively-hardened latent correctness fix, not an urgent operational priority. Signals are internally consistent (all sources agree it is a local, hypervisor-boundary kernel bug) except the vendor severity, which conflicts with the local/config-gated nested-virt exploitation reality.
Exploit ScenarioDerived

On an Intel host running KVM with nested virtualization enabled, a malicious or buggy L1 hypervisor guest reassigns L2's VPID, triggers a deliberately-failing nested VM-Enter (updating last_vpid without flushing), then performs a successful VM-Enter, causing the CPU to reuse stale TLB translations. This can corrupt L2 guest memory mappings, leading to wrong translations, guest instability/crashes, and potentially cross-context data exposure. No public exploit code is identified at time of analysis, and exploitation depends on a specific timing/ordering sequence.
Act Now Prioritize within 24-48h. Why: CRITICAL severity.
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 – Sep 16, 2026

Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stale guest translations active after a failed nested VM-Enter, causing KVM to miss a required TLB flush when L1 changes L2's VPID. Only hosts running Intel VMX with KVM nested virtualization explicitly enabled (nested=1) are affected; an attacker who already controls an L1 hypervisor guest vCPU with the ability to manipulate nested VMCS state could reassign L2's VPID, force a nested VM-Enter to fail, and then perform a successful VM-Enter so the missed flush leaves stale address translations in place. The independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - local hypervisor context, non-default configuration, no confidentiality impact, limited integrity and availability impact - and notes it is not exploitable against default (non-nested) KVM deployments; no public exploit code or confirmed active exploitation has been identified at time of analysis.

RemediationAI

Apply the vendor-released kernel update for your branch: 5.15.221, 6.1.188, 6.6.157, 6.12.110, or 6.18.51 on the stable trees, or 7.2.5 / 7.3-rc1 on mainline, all of which include the fix that services local TLB flushes on failed nested VM-Enter (see the stable commits at https://git.kernel.org/stable/c/c0c66cd575e31218da6a7d104c6ef80b0830b60c, https://git.kernel.org/stable/c/1025b938dc439b75c720a568a855a13eeb245686, https://git.kernel.org/stable/c/312cdb6d8940827dea63a7a52fb714a5049f06d1, https://git.kernel.org/stable/c/f74fccdf4f7fb0780cd84944108d35f3d9dc46a7, https://git.kernel.org/stable/c/c43563e7518e65ec6ccaa6a65f84c5af5ca5d379, https://git.kernel.org/stable/c/62c3ee4c9f0e2efef5157358b3549e50ede96d73, and https://git.kernel.org/stable/c/05a0b701d1089fb57beeb8982f23c3bbafe0fa8b, with the NVD entry at https://nvd.nist.gov/vuln/detail/CVE-2026-89930). If patching must be deferred, the most direct compensating control is to disable KVM nested virtualization on Intel hosts (for example by unloading the kvm_intel module and reloading it with 'nested=0', or setting the equivalent module option permanently), which removes the L2 VM-Enter path entirely; the trade-off is that L1 guests can no longer run their own nested guests, breaking nested-hypervisor and some container/VM-in-VM workloads. Disabling VPID (vpid=0 or nested VPID use) does not reliably mitigate the issue and generally degrades TLB performance, so it should not be relied upon. As a scoping control, restrict the ability to run nested guests to trusted tenants and avoid granting untrusted workloads the guest privileges needed to manipulate nested VMCS state, while keeping kvm_intel updated on any host that must retain nested virtualization enabled.

Affected VersionsENISA

Linux patch: 6.6.157
Linux patch: 6.18.51
Linux patch: 7.2.5
Linux patch: 7.3-rc1
Linux 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 <c0c66cd575e31218da6a7d104c6ef80b0830b60c
Linux 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 <62c3ee4c9f0e2efef5157358b3549e50ede96d73
Linux patch: 0
Linux 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 <1025b938dc439b75c720a568a855a13eeb245686
Linux patch: 6.1.188
Linux 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 <f74fccdf4f7fb0780cd84944108d35f3d9dc46a7
Linux 4.4
Linux patch: 5.15.221
Linux patch: 6.12.110
Linux 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 <05a0b701d1089fb57beeb8982f23c3bbafe0fa8b
Linux 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 <312cdb6d8940827dea63a7a52fb714a5049f06d1
Linux 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 <c43563e7518e65ec6ccaa6a65f84c5af5ca5d379

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.

Sign in to check
Technical ContextAI · show details

This is a correctness bug in KVM's nested virtualization support for Intel VT-x (nVMX). KVM maintains a last_vpid value tracking the VPID that L1 last used for L2, and queues TLB flushes when a transition requires them (for example via nested_vmx_transition_tlb_flush(), when VPID is disabled for L2, or when an MSR-load list architecturally mandates a TLB update). Those queued flushes are serviced on "full" nested VM-Exits through __nested_vmx_vmexit(), but not on the failure path of a nested VM-Enter such as when nested_vmx_enter_non_root_mode() rejects the VMCS. Because nested_vmx_transition_tlb_flush() updates last_vpid even when the VM-Entry ultimately fails, a failed entry that updates last_vpid without flushing, followed by a successful entry, can leave translations cached under the previous VPID live in the TLB - the SDM is ambiguous about whether a failed VM entry flushes the TLB, so the upstream fix simply always services queued local TLB flushes in this case. The flaw is a state-management/ordering error (no CWE was assigned in the source data) rather than a memory-safety defect, and its consequences are confined to stale translation state visible within the virtualized environment.

Know when KVM gets its next vulnerability

  • 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
Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Sources disagree (Medium–Critical)
Vendor (Linux) PRIMARY 9.3 CRITICAL
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
vuln.today AI 6.4 MEDIUM

Local hypervisor-guest context (AV:L, PR:L), specific VPID/failed-entry ordering (AC:H), guest→host boundary (S:C); impact is stale-TLB corruption - availability-dominant (A:H) with weak integrity (I:L) and no clear confidentiality.

3.1 AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
SUSE 4.5 HIGH
AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
Red Hat 7.0 MEDIUM

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

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

Lifecycle Timeline

4
CVSS changed
Sep 16, 2026 - 15:22 NVD
9.3 (CRITICAL)
Patch available
Sep 16, 2026 - 11:03 EUVD
CVE Published
Sep 16, 2026 - 10:32 cve.org
UNKNOWN (no severity yet)
CVE Published
Sep 16, 2026 - 10:32 cve.org
CRITICAL 9.3

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

KVM: nVMX: Service local TLB flushes on failed nested VM-Enter

KVM services local TLB flushes on "full" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()).

However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says:

If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition.

The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case.

More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.

Executive ViewAI

Why It Matters

CVE-2026-89930 is a flaw in the Linux kernel's KVM nested-virtualization support that can leave stale memory translations active on Intel-based virtualization hosts, potentially destabilizing or crashing the hypervisor itself. Exposure is narrow: only hosts where nested virtualization has been deliberately enabled are affected, and exploitation requires an attacker to already hold a privileged position inside a guest hypervisor, so standard KVM deployments are not at risk. Leadership should still prioritize remediation because these hosts are typically shared, multi-tenant virtualization platforms where a hypervisor-level failure can take many downstream workloads offline at once.

Business Impact: Medium
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 92% exploitable
Prevalence
Medium
Intel KVM is widely deployed but nested VMX is a non-default niche configuration
Data Quality
5 sources
Confidence: Medium
EUVD NVD CVE.org EPSS MSRC Vendor

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 CRITICAL
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
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
Medium

Priority Score

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

Attack Technique

Information Disclosure MEDIUM

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

Denial of Service MEDIUM

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

More in KVM

View all
CVE-2026-27211 CRITICAL
10.0 Feb 21

Arbitrary host file exfiltration from Cloud Hypervisor VMM versions 34.0-50.0. CVSS 10.0. Patch available.
CVE-2026-89918 CRITICAL
9.3 Sep 16

Address-rollover bug in the Linux kernel's KVM/arm64 TLB-by-VA invalidation path causes the hypervisor to silently skip

CVE-2026-89916 CRITICAL
9.3 Sep 16

Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed f
CVE-2026-89915 CRITICAL
9.3 Sep 16

Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations fo
CVE-2026-89914 CRITICAL
9.3 Sep 16

Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range
CVE-2026-89913 HIGH
8.8 Sep 16

A use-after-free race in the arm64 KVM vGICv3 code path of the Linux kernel (vgic_v3_save_pending_tables) allows a local
CVE-2026-89959 HIGH
8.8 Sep 16

The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access
CVE-2026-89957 HIGH
8.8 Sep 16

Stale hardware access to unplugged crypto resources in Linux KVM guests on IBM Z (s390) stems from a logic error in the

CVE-2026-89932 HIGH
8.8 Sep 16

Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on

CVE-2026-89929 HIGH
8.8 Sep 16

Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM execu
CVE-2026-89908 HIGH
8.8 Sep 16

On LoongArch hosts running KVM, a memory-slot update that changes only flags (KVM_MR_FLAGS_ONLY, most notably toggling K
CVE-2026-89960 HIGH
8.8 Sep 16

A use-after-free (CWE-416) in the Linux kernel's s390/vfio-ap AP crypto passthrough driver allows a local attacker with

Same technique Denial Of Service

View all
CVE-2015-5119 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2011-0611 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8
CVE-2012-0507 CRITICAL POC
9.8
CVE-2014-1761 HIGH POC
7.8
CVE-2015-5122 CRITICAL POC
9.8
CVE-2011-0609 HIGH POC
7.8

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

References

Advisories & patches
ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-89930 ADVISORY https://ubuntu.com/security/notices/USN-8959-1 ADVISORY https://ubuntu.com/security/notices/USN-8960-1 ADVISORY https://ubuntu.com/security/notices/USN-8961-1 ADVISORY https://ubuntu.com/security/notices/USN-8962-1 ADVISORY https://ubuntu.com/security/notices/USN-8963-1 REF https://git.kernel.org/stable/c/05a0b701d1089fb57beeb8982f23c3bbafe0fa8b REF https://git.kernel.org/stable/c/1025b938dc439b75c720a568a855a13eeb245686 REF https://git.kernel.org/stable/c/312cdb6d8940827dea63a7a52fb714a5049f06d1 REF https://git.kernel.org/stable/c/62c3ee4c9f0e2efef5157358b3549e50ede96d73 REF https://git.kernel.org/stable/c/b577a7cd6d984dd430af88ee1c9e03da71b73ee0 REF https://git.kernel.org/stable/c/c0c66cd575e31218da6a7d104c6ef80b0830b60c REF https://git.kernel.org/stable/c/c43563e7518e65ec6ccaa6a65f84c5af5ca5d379 REF https://git.kernel.org/stable/c/f74fccdf4f7fb0780cd84944108d35f3d9dc46a7

Search Externally

GitHub PoC Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC
Back

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