Linux Kernel CVE-2026-64516

Exploitation requires: (1) target system must have AMD GPU hardware with VCE version 1 (Southern Islands / Sea Islands generation, e.g., Radeon HD 7700-7900 series) physically installed and the amdgpu kernel module loaded; (2) attacker must have local authenticated access (PR:L) - remote unauthenticated exploitation is not possible given AV:L; (3) kernel version must fall between the introducing commit d4a640d4b9f34aa9472c71986ef4b5a42dbe4f0f and the respective fix commits. Exploitation is limited by: old/rare AMD VCE 1 hardware (uncommon in modern production), the need for physical or SSH-level local access, and no known weaponized exploit code. The scope change (S:C) applies only if OOB write is reliably turned into a kernel code execution primitive, which raises practical complexity beyond AC:L.

The vendor-assigned CVSS 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) with scope change reflects a worst-case kernel privilege escalation, but AC:L overstates exploitability in practice. Exploitation requires a system with old AMD GPU hardware featuring VCE 1 (a hardware component discontinued over a decade ago), a kernel in the affected range, and local access. EPSS at 0.20% (10th percentile) aligns with the niche hardware dependency - this is not a broadly targetable flaw. No KEV listing and no public exploit code further reduce urgency. The S:C/C:H/I:H/A:H impact vector is plausible if an OOB write in kernel driver context is weaponized into a privilege escalation, but achieving reliable exploitation would require careful memory layout manipulation, raising effective complexity above AC:L. Real-world risk is low: the affected hardware is rare in modern production deployments, and exploitation would yield local kernel compromise on an already-accessed system.

A local attacker with a standard user account on a workstation or server equipped with a legacy AMD GPU (e.g., Radeon HD 7000 series with VCE 1), running an unpatched kernel, triggers the out-of-bounds access through normal GPU driver initialization or a crafted firmware blob placed in the firmware search path with appropriate local write privilege. If the OOB write is shaped to overwrite adjacent kernel structures, the attacker could escalate to root. No public exploit code exists at time of analysis.