Look up another CVE · open CVE-2026-89930 in the interactive tracker
CVE-2026-89930
KVM: nVMX: Service local TLB flushes on failed nested VM-Enter
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89930 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/x86/kvm/vmx/nested.c
- What this is
- KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)MAINTAINERS section matched on arch/x86/kvm/*/ · kvm@vger.kernel.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid, bookworm · linux-6.12?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/x86
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.4 | 5.15.221 | c0c66cd575e3 |
| 4.4 | 6.1.188 | 1025b938dc43 |
| 4.4 | 6.6.157 | 312cdb6d8940 |
| 4.4 | 6.12.110 | f74fccdf4f7f |
| 4.4 | 6.18.51 | c43563e7518e |
| 4.4 | 7.2.5 | 62c3ee4c9f0e |
| 4.4 | 7.3 | 05a0b701d108 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- An L1 nested hypervisor reaches nested_vmx_enter_non_root_mode() by executing VMLAUNCH/VMRESUME (handle_vmlaunch/handle_vmresume) during KVM_RUN, or via KVM_SET_NESTED_STATE; this is local KVM ioctl/guest execution, not a network, adjacent-radio, or physical-device path.
- AC:LAttack complexity, low
- L1 fully controls vmcs12, can change virtual_processor_id so nested_vmx_transition_tlb_flush() updates last_vpid and queues KVM_REQ_TLB_FLUSH_GUEST, then fail VM-Enter after that point (invalid guest state or MSR-load list failure) and retry successfully; nested=1 and enable_vpid=1 are kvm_intel defaults, with no attacker-uncontrollable race.
- PR:NPrivileges required, none
- Exploitation requires no host root or init-namespace capabilities beyond running nested VMX in a tenant KVM guest; kvm_intel nested=1 is default, so a cloud tenant triggers the bug from guest CPL0 VMLAUNCH without host privileges or special capabilities.
- UI:NUser interaction, none
- No victim user or administrator action is required; the attacker drives the VPID change, the failed nested VM-Enter, and the subsequent successful enter entirely from their own nested-virtualization workload.
- S:CScope, changed
- Host KVM fails to INVVPID L2's hardware VPID (vpid02) on a failed nested VM-Enter after last_vpid is updated, so stale guest/combined TLB entries persist across nested contexts and can skip the first-use flush KVM relies on after VPID reuse, crossing the KVM nested guest-to-hypervisor isolation boundary.
- C:HConfidentiality impact, high
- Missed INVVPID leaves stale combined GVA-to-HPA mappings for L2's hardware VPID; after a vpid12 change (or a skipped first-use flush when last_vpid is updated on a failed enter), nested code can read pages L1 already remapped to another L2 or to L1 hypervisor memory, a translation-cache use-after-invalidate disclosure primitive.
- I:HIntegrity impact, high
- The retained combined mappings remain writable, so L2 (or a later nested guest on the same hardware VPID) can write through stale translations into pages L1 already remapped, yielding a use-after-invalidate write primitive against nested-hypervisor or sibling-guest memory.
- A:HAvailability impact, high
- Stale nested TLB entries produce wrong translations that can crash or hang the L1 hypervisor and L2 guests, and inconsistent KVM MMU/VPID state can oops the host; the attacker can repeat the failed-then-successful VM-Enter sequence at will.