Linux Kernel CVE-2026-31591

Exploitation requires: (1) local system access with privileges sufficient to perform KVM vCPU ioctls - typically root or kvm group membership on the host; (2) an AMD EPYC processor with SEV-SNP support enabled in firmware and kernel; (3) an active SNP guest launch sequence in progress (the KVM_SNP_LAUNCH_FINISH ioctl must be in flight). The race window exists only during SNP guest initialization, not during normal guest operation. Limiting factors: the attack cannot be triggered remotely (AV:L), requires pre-existing KVM management privileges (PR:L), is timing-sensitive (concurrent thread must race the kernel path), and has no effect on non-SNP guests, Intel-based systems, or systems where SEV-SNP is not configured. The vulnerable code path is guarded by AMD hardware and firmware prerequisites that are absent in most general-purpose Linux deployments.

Real-world risk is moderate-to-low despite the CVSS 5.5 Medium rating, and all available signals converge on this assessment. The CVSS vector AV:L/AC:L/PR:L indicates local access with low-privilege requirements - on a KVM host, this realistically means root or kvm-group membership with direct vCPU ioctl access. The EPSS score of 0.02% (4th percentile) places this well below the threshold of active attacker interest. There is no CISA KEV listing and no public exploit code identified. The impact is confined to availability (A:H, C:N, I:N), meaning the worst-case outcome is a host kernel crash - serious in a production hypervisor environment but with no data exfiltration or integrity consequence. The primary concern is insider-threat or container-escape scenarios where an attacker already controls a KVM management process. No conflicting signals are present: CVSS vector, description, and EPSS all agree this is a local, low-probability, DoS-only issue restricted to AMD SEV-SNP KVM deployments.

A local attacker with root or kvm-group privileges on a KVM hypervisor running AMD SEV-SNP guests issues a KVM_SNP_LAUNCH_FINISH ioctl to trigger VMSA synchronization while simultaneously firing concurrent vCPU manipulation ioctls (e.g., KVM_SET_REGS or KVM_RUN) from a separate thread. The missing vCPU lock allows both operations to proceed concurrently, corrupting the VMSA state mid-encryption and triggering a kernel BUG or panic, crashing the host. No public exploit code has been identified for this race condition.