CVE-2026-98715
UnknownSummary
In the Linux kernel's KVM SVM, a failed VMRUN resets the VMCB's TLB control, effectively dropping the requested TLB flush. The fix preserves TLB control on failed VMRUN and tracks the need to flush all ASIDs on a per-CPU basis.
Risk Assessment
Dropping a TLB flush can lead to stale TLB entries, causing memory inconsistency and potential isolation issues between virtual machines.
Recommendation
Update the Linux kernel to a version containing the fix that preserves TLB control on failed VMRUN.
Other vulnerabilities in Linux kernel (KVM SVM)
See all- CVE-2026-98716Unknown
In the Linux kernel's KVM SVM, the check for whether an MSR access is intercepted uses the MSR permission bitmap of the active VMCB instead of assuming vmcb02's bitmap is always used. KVM uses msrpm02 only when L1 wants to intercept MSR accesses.
- CVE-2026-98714Unknown
In the Linux kernel's KVM SVM, the control.erap_ctl and control.clean fields in the VMCB are not updated when VMRUN fails. Per AMD, there is no guarantee that requested actions were performed, so updating these fields can mislead KVM.
Original NVD description (English source)
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 FLUSH_ALL_ASID with TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid(). Deliberately don't bother saving/restoring the "old" tlb_ctl on failure, in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID 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 new_asid() 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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS