Look up another CVE · open CVE-2026-72287 in the interactive tracker
CVE-2026-72287
KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72287 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a "late" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.
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?
- ?
- 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-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 3.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.19 | 7.1.5 | 7d066368f72e |
| 6.19 | 7.2 | ebdac7554abb |
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
- The bug is reached when an L1 nested-hypervisor guest executes VMLAUNCH/VMRESUME, driving KVM nested VM-Enter handling during KVM_RUN; no network, adjacent-radio, or physical-access path reaches this nVMX code.
- AC:HAttack complexity, high
- Exploitation requires host EPT disabled (enable_ept=0) and the off-by-default developer warn_on_missed_cc module parameter; both are non-default host settings the attacking guest cannot enable, even though VMCS12/vAPIC fields are attacker-controlled once present.
- PR:LPrivileges required, low
- The attacker needs ring-0 inside an L1 guest VM with nested VMX available (a typical nested-virt cloud tenant running its own hypervisor); no init-namespace host root or CAP_SYS_ADMIN on the host is required beyond ordinary VM execution.
- UI:NUser interaction, none
- Once nested virtualization is available, the malicious L1 hypervisor triggers the flaw solely via its own VMX instructions and crafted VMCS12/virtual-APIC state; no separate victim user action is required.
- S:CScope, changed
- Failure to restore vmcs01.GUEST_CR3 after the late VM-Fail leaves KVM running L1 with L1-controlled paging instead of KVM shadow CR3, crossing the guest/hypervisor isolation boundary in the classic KVM nested VMX guest-to-host escape class.
- C:HConfidentiality impact, high
- Running L1 with its own CR3 under shadow paging (EPT disabled) lets the guest use attacker-chosen page tables to read host physical memory and kernel data outside its memslots, yielding arbitrary host information disclosure.
- I:HIntegrity impact, high
- The same CR3 confusion gives L1 arbitrary control over host physical mappings, enabling modification of host kernel structures and potential host code execution rather than a benign, correctly unwound VM-Fail.
- A:HAvailability impact, high
- Beyond VM escape, inconsistent host CR3/paging state can oops or panic the host kernel when KVM resumes L1, denying availability to all co-resident VMs on the hypervisor.