Linux Kernel EUVD-2026-80530

| CVE-2026-89930 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

Access

Gain code execution in L1 hypervisor guest
Delivery

Enable/use nested VMX with L2 VPID
Exploit

Change L2 VPID then force failed VM-Enter
Execution

Perform successful VM-Enter reusing stale TLB
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.

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

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 Act Now

Arbitrary host file exfiltration from Cloud Hypervisor VMM versions 34.0-50.0. CVSS 10.0. Patch available.

CVE-2026-89918 CRITICAL Act Now

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 Act Now

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 Act Now

Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations fo

CVE-2026-89914 CRITICAL Act Now

Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range

CVE-2026-89913 HIGH This Week

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 This Week

The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access

CVE-2026-89957 HIGH This Week

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 This Week

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 This Week

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 This Week

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 This Week

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

CVE-2011-2462 CRITICAL POC

CVE-2011-0611 HIGH POC

CVE-2012-1889 HIGH POC

CVE-2012-0507 CRITICAL POC

CVE-2014-1761 HIGH POC

CVE-2015-5122 CRITICAL POC

CVE-2011-0609 HIGH POC

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

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