Linux Kernel EUVD-2026-45529

Exploitation requires local access to the machine and, specifically, an open handle to the AMD GPU device (a render/DRI node such as /dev/dri/renderD128) so the attacker can issue command-submission (CS) IOCTLs; the target must run an AMD GPU whose amdgpu driver instantiates the JPEG v4.0 IP ring. The concrete trigger is a CS submission that includes a user fence directed at the JPEG v4.0 ring, which the hardware cannot service with 64-bit user-fence writes. Limiting factors: it is not remotely exploitable (AV:L), requires low but non-zero privileges (PR:L - access to the render or video group, not a fully unprivileged remote actor), needs no user interaction, and only affects deployments with the specific AMD JPEG v4.0 hardware/driver path; systems without AMD GPUs or without that IP block are unaffected.

The CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H yields 7.8 (High) and describes a locally exploitable, low-complexity flaw requiring only low privileges and no user interaction, with high impact to all three properties - consistent with GPU-driver memory corruption reachable by any user holding a render-node handle. Countervailing signals point to lower real-world urgency: EPSS is only 0.17% (7th percentile), the CVE is NOT on CISA KEV, and no public proof-of-concept was reported (no public exploit identified at time of analysis). There is a notable tension between the vendor tag 'Information Disclosure' and the CVSS C:H/I:H/A:H (which implies full corruption/DoS, not merely disclosure); this discrepancy should be verified - the practical impact of an unsupported ring fence write may range from a device hang (DoS) to limited memory disclosure or corruption depending on where the fence value lands. Because the attack vector is local (no network reachability) and confined to systems actually running AMD GPUs with the JPEG v4.0 IP block, this is a moderate-priority patch: routine kernel-update hygiene rather than emergency response, prioritized on multi-user hosts and workstations where untrusted local users have GPU access.

A logged-in local user, or a low-privileged process such as a sandboxed application or container with GPU access, opens the amdgpu render node and submits a crafted command-stream job targeting the JPEG v4.0 ring while requesting a 64-bit user fence write. Because the ring lacks user-fence support, the unsupported write corrupts or hangs GPU state, potentially yielding denial of service or memory corruption on the host. No public proof-of-concept is currently known, and the local, low-complexity CVSS profile means exploitation requires only existing access to the GPU device.