Linux Kernel KVM EUVD-2026-32413

Exploitation requires: (1) local access to a system running the Linux kernel KVM subsystem with AMD-V (SVM) hardware support, (2) at minimum low-privileged access sufficient to create and operate nested virtual machines (L2 guests), and (3) nested SVM must be enabled - this is a non-default configuration on most distributions, requiring explicit enablement of the kvm_amd nested=1 parameter. The attack cannot be conducted remotely or without VM control capabilities. Limiting factors: non-default nested virtualization configuration, local-only attack vector, and AMD-specific hardware requirement (Intel VT-x/VMX is unaffected). Systems using only Intel processors or not enabling kvm_amd with nested support are not vulnerable.

Real-world risk is moderate and tightly scoped. The CVSS 3.1 score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) correctly reflects a local-only, availability-only vulnerability requiring at least low-privileged access - the attacker must be able to operate within or control a nested VM environment on the target host. EPSS at 0.02% (6th percentile) signals very low exploitation probability, consistent with the niche prerequisite of nested AMD virtualization. The vulnerability is not listed in the CISA KEV catalog and no POC has been identified. From an SSVC perspective: exploitation is unlikely (no active exploitation confirmed), the attack is not automatable (requires local access and nested VM control), and technical impact is partial (host DoS only, no code execution path evident). The 'Code Injection' tag in the intelligence metadata conflicts with both the description and the CVSS impact vector (C:N/I:N); this tag should be disregarded. The primary concern is a host hypervisor crash affecting all co-hosted VMs, making this relevant for cloud/VPS providers running AMD-based nested virtualization workloads.

A local user with sufficient privileges to configure and launch a nested guest VM (L2) on an AMD-V host running an affected kernel engineers a condition where the nested #VMEXIT triggers a CR3 load failure - for example by crafting an invalid host-state area before VMRUN. On an unpatched kernel, the error is silently discarded and the L1 hypervisor continues executing against corrupt page-table mappings, leading to a host kernel crash and DoS affecting all co-hosted virtual machines. No public POC exists for this scenario.