CVE-2026-98716: KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In KVM's SVM MSR-interception checks, use the MSR permission bitmap of the active VMCB rather than always using vmcb02/msrpm02; do not cache the bitmap's virtual address, since __va() is cheap and caching can introduce stale information.
Event History
Frequently Asked Questions
Which deployments are in scope?
The issue is in KVM's SVM nested-virtualization handling. It is relevant when an L2 guest is active; deployments that do not use nested guests are not described as exercising this path.
What configuration detail determines which MSR bitmap should be used?
KVM uses msrpm02 only when the L1 guest wants to intercept MSR accesses, because KVM must then merge msrpm01 with msrpm12. The fix checks the bitmap of the active VMCB instead of assuming vmcb02's bitmap is always in use while L2 is active.