Linux Kernel EUVD-2026-80532

| CVE-2026-89932 HIGH

2026-09-16 Linux

GHSA-8q77-gpg3-wgrc

Denial Of Service Information Disclosure Linux KVM

8.8

CVSS 3.1 · Vendor: Linux

View

Attack ChainAIDerived

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

Access

Gain code execution in L1 guest with nested VMX
Delivery

Toggle VMXOFF then VMXON to free/realloc vpid02
Exploit

Launch L2 guest reusing stale VPID
Execution

Skipped first-use flush leaves stale TLB entries
Persist

L2 runs against stale translations
Impact

Cross-context memory corruption / host-visible DoS

Vulnerability Assessment

Exploitation Conditions	Requires the host to run KVM on x86 (Intel VMX) with nested virtualization enabled (kvm_intel nested=1) and an L1 guest that itself enables VPID for its L2 guests. The specific trigger is an L1 guest performing VMXOFF followed by VMXON, then running an L2 guest, where KVM reuses a vpid02 value that still has TLB entries resident on the physical CPU from a previous VPID lifetime - only then is the first-use flush skipped. Limiting factors: the attacker must already control an L1 guest (PR:L, local), success is probabilistic (depends on VPID reuse and physical-CPU TLB residency timing, i.e. AC:H), and hosts without nested virtualization or with L1 guests that do not use VPID are unaffected.
Impact	Signals are mixed and point to a LOWER real-world priority than the vendor's CVSS 8.8 suggests. The vendor vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H is internally inconsistent with the described mechanism: exploitation depends on a specific sequence (L1 executes VMXOFF then VMXON, runs an L2 guest, AND KVM happens to reuse a VPID that still has live TLB entries on the same physical CPU), which is a timing/state-reuse window, not the deterministic AC:L the score claims - AC:H is more honest. The triple-High C:H/I:H/A:H is also overstated: a stale-TLB isolation break most reliably yields nondeterministic guest-state corruption and DoS, with only speculative/partial disclosure, so C:L/I:L/A:H is a defensible impact profile. There is NO EPSS score, NO CISA KEV listing, and NO public POC in the provided data, so there is no evidence of exploitation pressure. SSVC-style reading: exploitation=none observed, automatable=no (requires nested-virt state manipulation and TLB residency luck), technical impact=partial. Net: this is a legitimate correctness bug worth patching on multi-tenant nested-virt hosts, but it is a high-CVSS/low-real-risk item for most fleets, not an emergency.
Exploit ScenarioDerived	A malicious or compromised L1 hypervisor guest on a KVM host repeatedly toggles VMXOFF→VMXON and launches L2 guests, hoping KVM re-allocates a VPID (vpid02) that still has stale TLB entries resident on the physical CPU from a prior VM's or vCPU's lifetime. If the first-use flush is skipped, the L2 guest transiently executes against stale address translations, causing memory-mapping corruption and likely crashes/hangs, with a theoretical chance of reading data mapped by a previous tenant. No public exploit code is identified, and success is probabilistic rather than reliable.

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.

AnalysisAIv1 – Sep 16, 2026

Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on x86 Intel VMX hosts, because vpid02 is not flushed on its first use after a VPID is recycled following an L1 guest's VMXOFF/VMXON cycle. Exploitation requires an attacker who already controls an L1 guest on a host running KVM with nested virtualization enabled (kvm_intel nested=1) where L1 uses VPID for its L2 guests, and success depends on KVM reusing a vpid02 value that still has TLB entries resident on the physical CPU, making the outcome timing- and reuse-dependent rather than deterministic. No public exploit has been identified at time of analysis, and our independent assessment rates the realistic impact well below the vendor's CVSS 8.8 - limited confidentiality and integrity loss with high availability impact under local, high-complexity preconditions (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H).

RemediationAI

Vendor-released patches are available: upgrade to Linux 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, or 7.2.5 (or 7.3-rc1 or later), or to your distribution's kernel build that carries the corresponding stable backports documented at https://git.kernel.org/stable/c/26de0d2d9a8d14c03e5ebb25fd68b5bfcd5ac366, https://git.kernel.org/stable/c/8bc609999ec223089fec8d74c7de27d689606b36, https://git.kernel.org/stable/c/62604376c313178811375f40a282fc2a46cd2311, https://git.kernel.org/stable/c/8b98d662ab24f34710a56e03bc9169e4a5508606, https://git.kernel.org/stable/c/22dfcc22c95e91295119a1c3b469816ce44c4804, https://git.kernel.org/stable/c/121991d150735f3c0f7401678ce4d35c5b4ac898, and https://git.kernel.org/stable/c/f0772389413dce9657c7d6950abf3edbbd511356. If patching cannot be completed immediately, the most effective compensating control is to disable nested virtualization on Intel hosts by loading kvm_intel with nested=0 (or setting the module parameter and reloading the module, which requires stopping all running VMs) - the trade-off is that L1 guests can no longer run their own nested VMs, which breaks legitimate nested-virtualization workloads. Further risk reduction comes from not granting untrusted or multi-tenant L1 guests access to nested VMX at all, since the attack prerequisite is control of an L1 guest that can issue VMXOFF/VMXON and enable VPID; restricting who may create or administer such guests and keeping host KVM/BIOS updated limits exposure but does not replace the kernel fix.

Affected VersionsENISA

Linux patch: 5.15.221

Linux 0 <7.2.5

Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <62604376c313178811375f40a282fc2a46cd2311

Linux patch: 6.12.110

Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <26de0d2d9a8d14c03e5ebb25fd68b5bfcd5ac366

Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <8b98d662ab24f34710a56e03bc9169e4a5508606

Linux 0 <6.6.157

Linux 0 <6.18.51

Linux 0 <6.12.110

Linux patch: 6.18.51

Linux 0 <5.15.221

Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <f0772389413dce9657c7d6950abf3edbbd511356

Linux patch: 6.1.188

Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <121991d150735f3c0f7401678ce4d35c5b4ac898

Linux 0 <6.1.188

Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <8bc609999ec223089fec8d74c7de27d689606b36

Linux patch: 6.6.157

Linux patch: 7.2.5

Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <22dfcc22c95e91295119a1c3b469816ce44c4804

Linux patch: 7.3-rc1

Affected Packages

euvd linux fix: 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5

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

KVM's nested VMX support lets an L1 hypervisor run its own L2 guests while KVM emulates VMX for L1. To keep address-translation caches coherent, Intel VMX uses VPIDs to tag TLB entries so that entries from one virtual processor are not confused with another; KVM allocates vpid02 for L2 and tracks the last VPID it flushed in last_vpid. The vulnerable code path failed to reset that tracking state when vpid02 was released on VMXOFF, so after L1 performs VMXOFF followed by VMXON and then runs an L2, the first VM-Enter could be treated as a VPID match and skip the required flush. Because VPID 0 is not legal in vmcs12 when L1 enables VPID, the intended behavior was for nested_vmx_transition_tlb_flush() to always detect a change on first use; that guarantee was lost, letting L2 observe stale TLB entries that may belong to a different vCPU or an entirely different VM. No CWE identifier was assigned by the vendor; the root-cause class is incomplete cleanup/invalidation of a cached translation resource across a virtualization lifecycle boundary. The affected CPE is cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*, and the EUVD range notation (1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < fix commits) indicates the defect has been present since the earliest Linux git history import, making it a long-lived latent flaw rather than a recent regression.

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

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 7.0 HIGH

Requires a compromised L1 guest (PR:L, AV:L) and a nondeterministic VPID-reuse/TLB-residency window (AC:H); guest→host isolation break is S:C; stale-TLB impact is DoS-dominant (A:H) with only partial C/I.

3.1 AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H

4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:H/SC:L/SI:L/SA:N

SUSE 7.9 HIGH

AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L

Red Hat 7.0 HIGH

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

Sep 16, 2026 - 15:22 NVD

8.8 (HIGH)

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

HIGH 8.8

DescriptionCVE.org

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

KVM: nVMX: Always flush vpid02 on first use

Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID.

This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM).

Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.

Executive ViewAI

Why It Matters

Linux kernel KVM nested virtualization on Intel VMX hosts has a high-severity flaw that can let an authenticated local attacker who already controls an L1 guest cause stale TLB reuse in L2 guests, resulting in limited confidentiality and integrity loss plus high availability impact. The realistic organizational exposure is concentrated in multi-tenant, cloud, VDI, or lab environments that enable nested KVM for untrusted tenants, and no public exploit identified at time of analysis; patch available per vendor advisory.

Business Impact: Medium

Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score

0.2%

Top 94% exploitable

Prevalence

Medium

x86 KVM is widely deployed but this needs nested virtualization enabled plus an L2 guest

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

Medium

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

Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stal

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-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-89932 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/121991d150735f3c0f7401678ce4d35c5b4ac898 REF https://git.kernel.org/stable/c/22dfcc22c95e91295119a1c3b469816ce44c4804 REF https://git.kernel.org/stable/c/26de0d2d9a8d14c03e5ebb25fd68b5bfcd5ac366 REF https://git.kernel.org/stable/c/62604376c313178811375f40a282fc2a46cd2311 REF https://git.kernel.org/stable/c/8b98d662ab24f34710a56e03bc9169e4a5508606 REF https://git.kernel.org/stable/c/8bc609999ec223089fec8d74c7de27d689606b36 REF https://git.kernel.org/stable/c/f0772389413dce9657c7d6950abf3edbbd511356

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