Look up another CVE · open CVE-2026-64172 in the interactive tracker
CVE-2026-64172
KVM: SVM: Disable AVIC IPI virtualization on Hygon Family 18h (erratum #1235)
Published 2026-07-19 (3 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-64172 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.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Hygon Family 18h CPUs are derived from AMD Family 17h (Zen1) silicon and share the same erratum #1235: hardware may read a stale IsRunning=1 bit during ICR write emulation and silently fail to generate an AVIC_IPI_FAILURE_TARGET_NOT_RUNNING VM-Exit on the sending vCPU. The absence of the VM-Exit causes KVM to miss the required wakeup of blocking target vCPUs, leading to hung vCPUs and unbounded delays in guest execution. Extend the existing AMD Family 17h erratum #1235 workaround to also cover Hygon Family 18h. With IPI virtualization disabled, KVM never sets IsRunning=1 in the Physical ID table, so every non-self IPI generates a VM-Exit and is correctly emulated.
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/svm/avic.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-07-19 (3 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.19%, higher than 8.6% 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.17 | 6.18.34 | 94ade38f317e |
| 6.17 | 7.0.11 | 9560e6fee887 |
| 6.17 | 7.1 | 9a12fa5213cf |
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
- Exploitation requires executing guest code that issues APIC ICR writes against blocking vCPUs; the vulnerable KVM/AVIC path is reached from within a VM, not from remote network packets to the host.
- AC:LAttack complexity, low
- The erratum is a race on IsRunning that the attacker fully controls by pinning one vCPU in a blocking halt/mwait state and having another vCPU send timed IPIs; no conditions outside attacker influence are required once AVIC is active.
- PR:NPrivileges required, none
- No host privileges are needed beyond the ability to run code in a tenant VM on a Hygon KVM host; a cloud customer with a standard VM instance can trigger the bug without host root or special capabilities.
- UI:NUser interaction, none
- No victim interaction is required; a malicious guest can autonomously orchestrate blocking and IPI traffic to hang vCPUs.
- S:CScope, changed
- In nested virtualization deployments, a malicious L1 hypervisor guest can cause hung vCPUs and unbounded execution delays in L2 guests via the host KVM AVIC path, crossing the L1/L2 security boundary even though there is no host escape.
- C:NConfidentiality impact, none
- The bug is a missed VM-exit and missed vCPU wakeup with no out-of-bounds access, use-after-free, or information disclosure primitive.
- I:NIntegrity impact, none
- No memory or data structures are corrupted; the failure only prevents delivery of required wake events to blocking vCPUs.
- A:HAvailability impact, high
- Missed wakeups cause hung vCPUs and unbounded delays in guest execution, constituting a reliable denial-of-service against VM availability.