CVE-2026-98719

Low risk· EPSS 5%

Published: 18/10/2026(UTC)Updated: 19/10/2026(UTC)Translated: 18/10/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.17%

5th percentile - higher than 5% of all known CVEs

Summary

In the Linux kernel's KVM SEV, the have_run_cpus mask pointer is not nullified after being freed, leading to a double-free in sev_vm_destroy() on the error path of __sev_guest_init(). The fix introduces a helper and nullifies the pointer after freeing.

Risk Assessment

A double-free can lead to heap corruption, kernel crashes, or potential privilege escalation in environments using SEV.

Recommendation

Update the Linux kernel to a version containing the fix that nullifies the have_run_cpus pointer after freeing the mask.

Other vulnerabilities in Linux kernel (KVM SEV)

CVE-2026-98718Low risk· EPSS 5%
In the Linux kernel's KVM SEV, cache maintenance is performed after clearing the SEV state on the source VM during intra-host migration. This creates a window where memory reclaim can free a page without a prior cache flush, and a subsequent hardware flush overwrites the new page owner's data with the guest's old ciphertext.

Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS