Look up another CVE · open CVE-2026-72285 in the interactive tracker
CVE-2026-72285
KVM: TDX: Reject concurrent change to CPUID entry count
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-72285 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
Reject KVM_TDX_INIT_VM if userspace changes cpuid.nent between the initial read and the subsequent copy of the initialization data. tdx_td_init() first reads user_data->cpuid.nent to size the flexible kvm_tdx_init_vm copy. The copied structure also contains cpuid.nent, and that field can differ from the value used to size the allocation if userspace modifies the input concurrently. setup_tdparams_cpuids() later passes init_vm->cpuid.nent to kvm_find_cpuid_entry2(), which uses it as the array bound for the copied entries. Require the copied count to match the value used to size the allocation so that CPUID parsing cannot access beyond the entries actually copied.
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/tdx.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:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.4% 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 | d6b5aba65e99 |
| 6.19 | 7.2 | cfbebb55e512 |
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 only via local KVM ioctls on /dev/kvm (KVM_CREATE_VM with KVM_X86_TDX_VM, then KVM_MEMORY_ENCRYPT_OP/KVM_TDX_INIT_VM); there is no network, guest, or remote packet path into tdx_td_init().
- AC:LAttack complexity, low
- This is a TOCTOU race where the attacker controls both sides by racing get_user(cpuid.nent) against concurrent writes to the same userspace kvm_tdx_init_vm buffer during memdup_user(), making the out-of-bounds CPUID walk reliably triggerable.
- PR:LPrivileges required, low
- Exploitation requires only the ability to open /dev/kvm and issue KVM_TDX_INIT_VM on a TDX VM, privileges routinely held by local virtualization users (kvm group) and hypervisor service accounts on TDX/confidential-compute hosts, not init-namespace root.
- UI:NUser interaction, none
- No victim interaction is required; a malicious or compromised VMM process drives the entire ioctl sequence and concurrent memory modification itself during TD VM initialization.
- S:UScope, unchanged
- Both the vulnerable KVM TDX host-kernel code and the impact (kernel heap disclosure/corruption during TD setup) sit within the host kernel security authority; this is not a guest-to-host VM escape or cross-authority sandbox breakout.
- C:HConfidentiality impact, high
- kvm_find_cpuid_entry2() uses the inflated cpuid.nent as the bound over a smaller memdup_user allocation, performing an out-of-bounds read of adjacent kernel heap memory whose contents are copied into td_params CPUID/EPTP fields (up to hundreds of entries).
- I:HIntegrity impact, high
- Out-of-bounds heap data is fed into td_params and passed to tdh_mng_init() for Trust Domain creation, letting an attacker influence TD CPUID and EPTP configuration with attacker-controlled kernel memory and enabling further memory-corruption exploitation.
- A:HAvailability impact, high
- Reading beyond the undersized kmalloc buffer can fault on unmapped slub memory or corrupt adjacent kernel objects during TD initialization, producing kernel oops/panic and denying service to all VMs on the host.