Linux Kernel EUVD-2026-32856

Exploitation requires: (1) local access to the target system with at least low-privilege user credentials (PR:L per CVSS vector); (2) an AMD GPU present and the amdkfd kernel module loaded (CONFIG_HSA_AMD=y); (3) access to the /dev/kfd device node, typically granted to members of the 'render' or 'video' group on Linux distributions. For the availability (crash) impact specifically, a multi-GPU environment running RCCL peer-to-peer collective operations is required - single-GPU workloads may encounter stale data but are unlikely to trigger the RCCL protocol handshake failure. The information-disclosure risk (reading stale VRAM) requires only the /dev/kfd device access and the amdkfd module, with no RCCL dependency. Exploitation is bounded to the vulnerable host; no network vector exists (AV:L). The vulnerability does NOT affect systems without AMD GPU hardware, kernels without amdkfd support, or allocations made via the standard GEM ioctl path (which correctly sets VRAM_CLEARED).

Real-world risk is moderate-low for most environments but significant for HPC and ML infrastructure running AMD ROCm multi-GPU workloads. The CVSS 3.1 base score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) correctly captures the local, low-privilege attack vector but rates confidentiality impact at N, which conflicts with both the NVD 'Information Disclosure' tag and the description's explicit statement that stale data is 'observable by compute kernels.' This discrepancy suggests the official CVSS may understate the full impact. EPSS of 0.02% (5th percentile) reflects that this is not a vulnerability targeted by opportunistic exploitation frameworks - it requires local GPU access and specialized knowledge of ROCm internals. There is no CISA KEV entry and no public proof-of-concept. The availability impact is high and reproducible in RCCL P2P configurations, making it a reliability defect more than a weaponizable exploit for most threat models. For ML training clusters and HPC systems running multi-node AMD GPU jobs, this represents a meaningful operational risk.

A local user on a multi-GPU compute node allocates a large VRAM buffer via the KFD interface (e.g., through the ROCm runtime) and reads its initial contents before writing any data; the buffer contains residual data from a previous process's GPU computation, potentially including model weights, intermediate activation values, or cryptographic material. In RCCL-based multi-node training jobs, the uncleared ptrExchange, head, and tail fields in newly allocated communication buffers cause the P2P handshake to interpret garbage as valid protocol state, crashing the collective operation and terminating the entire distributed training job. No public proof-of-concept code exists, but the crash is reproducible by any RCCL workload on unpatched kernels.