CVE-2026-98714 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability addressed involves a critical logic error within the Kernel-based Virtual Machine (KVM) implementation for AMD Secure Virtual Machine (SVM) architecture, specifically concerning the handling of virtualization control fields during VMRUN instruction execution failures. In x86 virtualization environments using SVM, the hypervisor utilizes specific control structures to manage guest state transitions and hardware-assisted virtualization features. The core issue arises from how KVM manages these control fields when the VMRUN instruction, which is responsible for transitioning a vCPU into guest mode, fails or returns an error code rather than successfully entering the guest environment. Historically, certain implementations may have proceeded to update internal state variables reflecting the new control field values even after detecting that the hardware did not accept the request. This behavior contradicts the architectural specifications provided by AMD regarding SVM operation under failure conditions.
According to AMD documentation and architectural guidelines for SVM, there is no explicit guarantee about the processor's behavior when VMRUN fails due to invalid or unsupported control settings. The specification implies that if the instruction does not complete successfully, the hardware may not have applied any of the requested changes to its internal state registers. Consequently, assuming that the control fields were updated by the hardware leads to a desynchronization between the hypervisor’s view of the virtual machine's configuration and the actual hardware state. This discrepancy creates a scenario where subsequent operations rely on stale or incorrect assumptions about which features are enabled or disabled in the guest context. Such misalignment can lead to unpredictable behavior, including potential privilege escalation vectors if security-related controls like nested paging or intercept masks were incorrectly assumed to be active when they were not actually applied by the hardware.
The operational impact of this flaw is significant for system stability and security integrity within virtualized environments. If a hypervisor proceeds with operations based on control fields that were never successfully committed by the CPU, it may enable features that are effectively disabled at the hardware level or disable features that remain active. This inconsistency can result in guest isolation failures, where one virtual machine might inadvertently access resources belonging to another VM or the host system due to incorrect enforcement of memory protection boundaries. Furthermore, it complicates debugging and troubleshooting efforts because the software state diverges from the hardware reality, making it difficult to predict how the vCPU will behave during subsequent execution cycles. In worst-case scenarios, this could allow a malicious guest operating system to exploit these inconsistencies to escape its sandbox or cause denial of service conditions by triggering undefined behavior in the hypervisor's virtualization engine.
To mitigate this vulnerability, the fix ensures that control fields such as erap_ctl and clean bits are only updated if VMRUN completes successfully without errors. This approach aligns with the principle of least trust regarding hardware state changes during failed transitions. By preserving the previous values of these control registers upon failure, the hypervisor maintains consistency between its internal data structures and the actual configuration enforced by the AMD processor. This correction prevents the accumulation of incorrect state assumptions that could accumulate over multiple VMRUN attempts. Administrators should ensure their KVM packages are updated to include this patch, which is typically distributed through standard Linux kernel update channels. Regularly applying security patches for virtualization components is essential to maintain robust isolation boundaries and prevent potential exploitation paths related to hardware-assisted virtualization control logic errors.
From a classification perspective, this issue relates to CWE-20 Improper Input Validation as the hypervisor failed to properly validate whether the hardware accepted its configuration requests before updating internal state. It also touches upon CWE-665 Incorrect Initialization since the initial assumption about post-failure state was flawed. In terms of attack vectors, while not directly exploitable via a single command without specific conditions leading to VMRUN failure with side effects, it falls under ATT&CK techniques related to virtualization escape or defense evasion through hypervisor manipulation if an attacker can induce controlled failures in the VMRUN path. Ensuring strict adherence to architectural guarantees during error handling is crucial for maintaining the integrity of hardware-assisted virtualization platforms.