A race condition exists in the Linux kernel’s handling of TDX virtual machine initialization: if userspace changes the CPUID entry count between the initial read and a later copy, the kernel may size the allocation based on one value but later process a different count. This mismatch can cause the CPUID parsing routine to read beyond the actually copied entries, potentially leading to kernel memory corruption. Such corruption could trigger a crash (denial of service) or provide a foothold for privilege escalation. The vulnerability is limited to environments that use KVM with TDX support and requires concurrent modification of the CPUID structure by an attacker or misconfigured application.

The flaw affects the Linux kernel across all official Linux distributions that ship the upstream kernel, regardless of specific distribution. No version restrictions are provided in the advisory; affected releases are those that have not yet incorporated the fix that enforces consistent CPUID entry counts during TDX VM initialization.

The CVSS score of 7.8 indicates a high severity vulnerability, while the EPSS score of <1% suggests a low likelihood of exploitation. However, the flaw’s existence in privileged kernel code and its reliance on a concurrent data race suggest a low to moderate exploitation difficulty for an attacker with kernel or KVM module access. The issue is not listed in the CISA KEV catalog, indicating that there are no publicly known exploits governing real-world usage. To exploit, an attacker would need to orchestrate a race condition while invoking KVM_TDX_INIT_VM, modifying the cpuid.nent field after the kernel’s initial read but before the subsequent copy. Successful exploitation would result in stack or heap corruption due to out‑of‑bounds array access, which could be leveraged to gain root privileges. Given the lack of readily available exploitation evidence, the immediate risk remains uncertain but the potential impact warrants timely patching.