CVE-2026-98714
UnknownSummary
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.
Risk Assessment
Incorrect tracking of control state after a failed VMRUN can lead to virtualization errors, guest state inconsistency, or potential security issues.
Recommendation
Update the Linux kernel to a version containing the fix that updates control fields only when VMRUN succeeds.
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-98715Unknown
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.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD: there's no explicit architectural guarantee about the behavior in the presence of VMRUN failures. So the best thing to do would be to assume that if VMRUN fails, the actions requested in the control fields may not have been performed.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS