CVE-2026-98715: KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN
Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only if VMRUN is successful, i.e. clearing TLB control on a failed VMRUN effectively drops a TLB flush.
Explicitly track the need to flush all ASIDs on a per-CPU basis, as the ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus, this also obviates the need to avoid clobbering FLUSHALLASID with TLBCONTROLFLUSHASID, e.g. in svmflushtlbasid().
Deliberately don't bother saving/restoring the "old" tlbctl on failure, in quotes because it's not exactly the old tlbctl, it's the tlbctl from after presvmrun(), but before updating tlbctl for flushallasids. If VMRUN fails and TLBCONTROLFLUSHALLASID is forced, then the next successful run of the VMCB may unnecessarily flush all ASIDs, which strictly speaking could result in noisy neighbor issues. However, the fact that newasid() is already guest-triggerable, because of KVM's flawed behavior of clearing the ASID on emulated INIT, means that a guest can already trigger a flush of all ASIDs at roughly the same rate. And once KVM stops clobbering the ASID on emulated INIT, or assigns a static ASID to each vCPU, this flaw goes away.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.15-1Fixed in 7.3.3-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.117 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.61 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Configuration
Preserve TLB control when VMRUN fails so a pending TLB flush is not dropped.
KVM SVM TLB control on failed VMRUN = Preserve the pending TLB flush; do not reset the VMCB TLB control to do nothing - Configuration
Prevent ASID reuse issues by stopping ASID clobbering on emulated INIT or assigning each vCPU a static ASID.
KVM SVM ASID handling on emulated INIT = Do not clobber the ASID, or assign a static ASID to each vCPU - Configuration
Track pending FLUSH_ALL_ASID operations on a per-CPU basis because ASID reuse is tied to the pCPU.
KVM SVM FLUSH_ALL_ASID tracking = Track the need to flush all ASIDs per pCPU
Event History
Frequently Asked Questions
Which systems are in scope?
The issue is specific to Linux kernel KVM using SVM. The provided data does not establish whether other KVM virtualization modes or default configurations are affected.
What condition causes the faulty behavior?
A VMRUN failure can cause KVM to clear pending TLB-flush control before the CPU has performed the requested flush. The fix retains the pending flush requirement and tracks full-ASID flushes on a per-CPU basis.
Is there any expected performance impact from the fix?
After a failed VMRUN, the next successful VMCB run may unnecessarily flush all ASIDs. The description notes that this can cause noisy-neighbor performance effects, but preserves the required TLB-flush behavior.
How can I check whether the fix is present?
Review the kernel source or applied stable patches for commits fd873c3d1b5240e80365f09e758e8c96b88a7cdb or 60d93c27859fb3ec5b5a689e24de303f166477d0. No affected or fixed kernel version numbers are provided.