CVE-2026-98716
UnknownSummary
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.
Risk Assessment
Incorrect MSR interception checks can lead to nested virtualization errors, potentially allowing bypass of control mechanisms or incorrect guest behavior.
Recommendation
Update the Linux kernel to a version containing the fix that uses the active VMCB's MSR bitmap when checking MSR interception.
Other vulnerabilities in Linux kernel (KVM SVM)
See all- 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.
- 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: Use the active VMCB's MSR bitmap when checking if MSR is intercepted Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM needs to merge msprm01 with msrpm12. Don't bother tracking the virtual address of the bitmap that's being used, as __va() is cheap on x86, and caching the virtual address would introduce yet another source of potentially stale information.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS