Linux Kernel CVE-2026-72095

Local access with at least standard user privileges (PR:L per CVSS) is required. The system must have an AMD GPU with the amdgpu kernel module loaded and accessible. The specific trigger is calling amdgpu_userq_wait_*() with a zero fence count - a condition that arises from the amdgpu driver's own code path and can be reached by an unprivileged user with access to the AMD GPU device node (typically /dev/dri/renderD*). The primary caller __dma_fence_unwrap_merge() is NOT vulnerable because it has a count 0 || count 1 fast-path guard; only amdgpu_userq_wait_*() lacks this protection. Systems without AMD GPU hardware, systems where the amdgpu module is not loaded, and systems where GPU device node access is restricted to privileged users or specific groups are not exposed to this exploit path.

The CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is an accurate reflection of the worst-case impact: a local low-privilege attacker on a system with AMD GPU hardware could exploit kernel memory corruption for full system compromise. However, real-world risk is substantially narrowed by the hardware prerequisite - only Linux systems with AMD GPUs and the amdgpu driver loaded are exposed through the documented vulnerable code path. The EPSS score of 0.21% at the 11th percentile is consistent with this limited attack surface, and the absence of a CISA KEV listing confirms no observed active exploitation at time of analysis. No POC code has been identified. The risk profile is: genuine and serious for multi-user Linux workstations, GPU compute clusters, and cloud instances with AMD GPU passthrough; negligible for the vast majority of Linux deployments without AMD GPU hardware. This is not a 'high-CVSS-but-low-risk' dismissal - the C/I/A:H ratings are credible for kernel memory corruption - but exploitation is hardware-gated and requires local access, making this a routine kernel patching priority rather than an emergency response.

A local user on a Linux workstation or GPU compute node with an AMD GPU crafts a userqueue wait ioctl call that results in amdgpu_userq_wait_*() being invoked with a zero fence count. The missing guard in this path causes dma_fence_dedup_array() to return 1, leading to a dereference of an uninitialized fence pointer in the array - resulting in a kernel memory read of an arbitrary location, potential oops, or a memory corruption primitive that an experienced attacker could chain into privilege escalation. No public exploit code has been identified at time of analysis.