CVE-2026-98720 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified
Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the runtime eVMCS controls (pin, primary, secondary, etc.) are being updated. If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and then runs the same L2 with TPR virtualization disabled, KVM will fail to refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or L1 by proxy) read and write L0's TPR.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified within the Linux kernel’s KVM nested VMX implementation stems from an incomplete state synchronization mechanism when managing runtime eVMCS controls during nested virtualization operations. Specifically, the flaw occurs in the logic that handles updates to control fields such as pin-based, primary processor-based, and secondary processor-based controls. When a level one hypervisor modifies these runtime controls while running a level two guest, KVM is required to refresh the MSR bitmap for vmcs02 to ensure that hardware interception behaviors align with the new configuration. The failure to enforce this refresh creates a discrepancy between the intended virtualization policy and the actual hardware state exposed to the nested guest.
The operational impact of this defect is most evident in scenarios involving Task Priority Register (TPR) management. If L1 configures L2 to utilize TPR virtualization, it typically expects KVM to intercept writes to the physical CPU’s TPR on behalf of L2. However, if L1 subsequently modifies its configuration to disable TPR virtualization for a subsequent execution context or VM-Enter operation without triggering a full MSR bitmap refresh, the hardware continues to operate under the previous interception rules. Consequently, even though TPR virtualization is technically disabled in the control structures, the lack of an updated MSR bitmap means that writes and reads to the L0 host’s Task Priority Register are not intercepted by KVM but instead passed directly through to the physical CPU.
This failure results in a critical security boundary violation where L2 or L1 acting as a proxy can read and write the TPR of the underlying hypervisor, which is designated for use only by the privileged level zero software. The Task Priority Register controls interrupt priorities on x86 processors; unauthorized access allows an unprivileged nested guest to potentially manipulate hardware interrupt handling mechanisms. This could lead to denial-of-service conditions by masking critical interrupts or facilitate privilege escalation if combined with other vulnerabilities that exploit altered interrupt states. It represents a breakdown in the isolation guarantees expected between virtualization layers, allowing lower-privilege entities to interfere with host-level resource management.
From an industry standards perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-754: Improper Check for Unusual or Exceptional Conditions within system state transitions. The root cause is a failure to validate that all dependent hardware structures are synchronized following control changes. In the context of the MITRE ATT&CK framework, this flaw facilitates lateral movement and privilege escalation techniques by allowing an attacker operating within a nested VM to interact with host-level resources, potentially leading to Control Privilege Escalation (T1068) or Defense Evasion through manipulation of system interrupt handling mechanisms.
Mitigation for this issue requires the application of vendor-provided kernel patches that enforce strict synchronization of the MSR bitmap whenever runtime eVMCS controls are modified. Administrators should ensure their systems are updated to versions containing these fixes. In environments where nested virtualization is not strictly required, disabling it at the hypervisor level reduces the attack surface by eliminating the complex state management logic associated with vmcs02 and eVMCS updates. Additionally, monitoring for unusual interrupt patterns or unexpected TPR modifications in host logs can help detect exploitation attempts of this specific flaw before significant damage occurs.