CVE-2026-98716 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in the Linux kernel involves a logic error within the Kernel-based Virtual Machine (KVM) subsystem specifically affecting AMD Secure Virtual Machine (SVM) implementations. The core issue stems from an incorrect assumption regarding which Memory Control Block VMCB MSR permission bitmap is active during nested virtualization scenarios. In SVM architecture, when Layer 2 guest operating systems are running under a Layer 1 hypervisor, KVM manages two primary VMCB structures: vmcb01 for the L1 hypervisor and vmcb02 for the L2 guest. The flaw arises because the code previously assumed that whenever an L2 context is active, the MSR interception bitmap associated with vmcb02 is always the one being checked or used by KVM internals. This assumption fails to account for cases where L1 has chosen not to intercept certain Model Specific Register accesses, meaning KVM does need to merge msrpm01 and msrpm12 into a single effective map stored in msrpm02. Consequently, relying on vmcb02's bitmap exclusively leads to incorrect interception decisions when the active state requires consulting different permission sets depending on whether L1 has opted out of intercepting specific MSRs.
This technical flaw results in improper handling of MSR interceptions which can lead to security and stability issues within virtualized environments. When KVM incorrectly determines that an MSR access is intercepted or not based on a stale or mismatched bitmap, it may either allow unauthorized accesses to sensitive hardware registers or unnecessarily trap benign operations causing performance degradation. In the context of nested virtualization, such errors compromise the isolation boundaries between L1 and L2 guests. An attacker controlling the L1 hypervisor might exploit this inconsistency to bypass intended security controls embedded in MSR interception logic, potentially gaining access to resources that should remain hidden from the guest OS or triggering undefined behavior within the host kernel due to mismatched state expectations.
From a standards perspective, this vulnerability aligns with CWE-20 Improper Input Validation as it involves failing to correctly validate which data structure represents the current execution context before making security-critical decisions. It also relates to CWE-697 Incorrect Comparison since the logic compares against an incorrect memory region or state representation. In terms of MITRE ATT&CK, this type of flaw facilitates privilege escalation and defense evasion techniques where a lower-level entity exploits misconfigurations in virtualization layers to escape containment or manipulate host behavior. The failure to dynamically determine the correct MSR bitmap based on actual interception requirements represents a classic case of hardcoding assumptions about runtime state rather than querying the authoritative source of truth for that specific moment.
The resolution involves modifying the KVM SVM code path to explicitly use the active VMCB's MSR permission bitmap when checking if an MSR is intercepted, ensuring alignment with the current virtualization context. The fix also removes unnecessary tracking of the virtual address of the bitmap being used. Since __va() conversions are computationally inexpensive on x86 architectures, caching these addresses was deemed counterproductive as it introduced a potential source of stale information. By eliminating this cache and directly referencing the active VMCB's bitmap, the code ensures that MSR interception checks always reflect the most current state defined by L1's configuration choices regarding which MSRs to intercept. This change simplifies the logic while enhancing correctness and reducing attack surface related to state synchronization errors in nested virtualization stacks.
To mitigate risks associated with this vulnerability, system administrators should ensure their Linux kernels are updated to versions containing the patch for this KVM SVM fix. For environments running nested virtualization workloads on AMD hardware, verifying that the host kernel version includes these corrections is critical to maintaining strict isolation guarantees between hypervisor layers. Additionally, organizations employing deep packet inspection or behavioral analysis tools focused on VM escape attempts should update their detection signatures to recognize anomalies related to MSR interception patterns in SVM contexts. Regular auditing of virtualization configurations and keeping all components of the cloud infrastructure stack up to date remain essential practices for preventing exploitation of such kernel-level logic errors that could otherwise lead to significant security breaches.