Linux Kernel EUVD-2026-32453

Exploitation requires all of the following: (1) the host CPU must be AMD with hardware SVM and nested-virtualization support enabled (Intel VMX hosts are not affected); (2) the KVM hypervisor must be running on the host with nested SVM enabled (kvm_amd module loaded with nested=1, which is the default on modern kernels); (3) the attacker must have code execution within a nested (L2) guest virtual machine - i.e., they are one hypervisor layer deep; (4) LBR (Last Branch Record) passthrough must be active or triggerable during the nested VM exit path. What limits exploitation: PR:L means local authenticated access inside the nested guest is required; pure remote network exploitation is not possible. The attack surface is further narrowed to environments that actually run nested VMs (cloud lab environments, CI/CD pipelines using nested KVM, security research environments), and specifically to AMD EPYC/Ryzen hosts - not Intel.

Real-world risk is moderate-to-low for most deployments despite the CVSS A:H rating. CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H indicates a local, low-privilege, low-complexity path to high availability impact - consistent with a nested-VM guest triggering a host KVM crash. However, AV:L and the nested-virtualization requirement significantly constrain the attack surface: the threat actor must already have code execution inside a nested (L2) guest on an AMD SVM host. EPSS at 0.02%/4th percentile and the absence of KEV listing or public POC confirm this is not under active mass exploitation. The 'Information Disclosure' tag provided by ENISA is in tension with the CVSS C:N rating; the LBR data involved in the copy could theoretically expose host branch-trace state to the nested guest, but this is not confirmed by vendor advisories and should be treated as unverified. Patch availability across three stable branches reduces urgency further. This is a genuine denial-of-service risk for cloud or lab environments hosting nested AMD VMs, not a broad-reaching vulnerability.

An attacker with code execution inside a nested (L2) AMD SVM guest on a vulnerable Linux KVM host crafts or triggers a sequence of VM exits involving LBR state, causing nested_svm_vmexit() to invoke svm_copy_lbrs() with vmcb12 as the destination. The resulting undefined modification of vmcb12 clean bits corrupts KVM's nested VMCB state, leading to a host kernel crash (BUG/oops) or hung virtual CPU, taking down all VMs on the affected host. No public proof-of-concept exists at time of analysis.