CVE-2026-98719 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it
Nullify have_run_cpus when freeing the mask, particularly in the error path of __sev_guest_init(), so that KVM doesn't have to subtly use sev->active to track whether or not the mask has been freed. As pointed out by Sashiko, blindly freeing the mask in sev_vm_destroy() results in a double-free if the mask is freed if __sev_guest_init() fails.
Throw the logic in a helper as nullifying the pointer is frustratingly difficult and weird due to have_run_cpus being a single-entry array when CPUMASK_OFFSTACK=n. Deliberately don't use CPUMASK_VAR_NULL, as it's not directly assignable when the cpumask is on-stack, e.g. requires using a local variable and a memcpy(), which is beyond ridiculous. Furthermore, while clearing the on-stack bitmask is an unnecessary and arguably unwanted side effect, KVM absolutely relies on '0' being the "null" value given that the struct is zero-allocated.
Opportunistically add an alloc() helper to pair with free(); there are just enough call sites to make doing so worthwhile.
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 Linux kernel vulnerability addressed in this update pertains to a critical memory management flaw within the Kernel-based Virtual Machine (KVM) subsystem, specifically affecting the Secure Encrypted Virtualization (SEV) implementation. The core issue stems from improper handling of the have_run_cpus mask pointer during resource deallocation sequences. In standard software engineering practices, freeing a dynamic memory allocation without subsequently nullifying the associated pointer creates a dangling reference. If this pointer is accessed or freed again later in the execution flow, it results in undefined behavior, most commonly manifesting as a double-free condition. This specific flaw was identified within the sev_vm_destroy function and the initialization path of __sev_guest_init(), where the lifecycle management of the cpumask structure lacked robust safeguards against premature or duplicate deallocation.
The technical root cause involves the interaction between memory allocation strategies and pointer state tracking in the kernel. The have_run_cpus variable is implemented as a single-entry array, which behaves differently depending on whether CPUMASK_OFFSTACK is enabled. When off-stack masking is disabled, the mask resides on the stack or within the structure itself, complicating standard nullification techniques. Developers attempted to avoid using CPUMASK_VAR_NULL because it requires complex memcpy operations for on-stack variables, leading to a reliance on implicit zero-initialization states. However, this approach proved fragile. If __sev_guest_init() fails after partially allocating resources but before fully establishing the active state, sev_vm_destroy may attempt to free memory that was either never allocated or already freed in an error handling path. This logic gap allowed for double-free scenarios because the code relied on checking sev->active rather than explicitly nullifying the pointer upon every potential exit point where freeing occurs.
From a security perspective, this vulnerability aligns with CWE-415 Double Free and CWE-762 Multiple Initializations of Resource. The exploitation vector typically involves triggering an error condition during SEV guest initialization to force the kernel into the flawed cleanup path. By inducing a double-free, an attacker could potentially corrupt heap metadata or overwrite adjacent memory structures. In the context of virtualization, such corruption can lead to privilege escalation from the guest environment to the host hypervisor level, compromising system integrity and confidentiality. The ATT&CK framework categorizes this under T1059 Command and Scripting Interpreter if leveraged for further exploitation, but more accurately reflects T1499 Endpoint Denial of Service or T1203 Exploitation for Credential Access depending on the specific outcome of the memory corruption.
The operational impact of this vulnerability is significant due to its location within the virtualization layer. A successful exploit could allow a malicious guest VM to crash the host system, resulting in a denial of service for all other tenants sharing that physical hardware. Alternatively, sophisticated attackers might leverage the heap corruption to execute arbitrary code on the host kernel, gaining full control over the infrastructure. This undermines the fundamental security guarantees provided by SEV, which is designed to protect workload confidentiality and integrity against hypervisor-level threats. The presence of such a flaw in error paths indicates that defensive programming practices were not consistently applied across all exit points in the initialization routine.
To mitigate this vulnerability, kernel developers implemented several structural changes. First, they introduced explicit nullification of the have_run_cpus pointer immediately after freeing it, ensuring that any subsequent access attempts result in a predictable NULL dereference rather than undefined memory corruption. Second, to address the complexity of handling on-stack versus off-stack masks without introducing cumbersome memcpy operations or relying on fragile zero-state assumptions, logic was refactored into helper functions. This encapsulation ensures consistent behavior across different compilation configurations and call sites. Additionally, an allocation helper function was added to pair with the free operation, promoting code reuse and reducing the likelihood of future inconsistencies in resource management. These changes enforce a stricter lifecycle policy where resources are explicitly managed and pointers are cleared upon release, aligning with secure coding standards for systems programming.