CVE-2026-74447

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

Exploitation requires local ioctl access to /dev/kfd (KFD_IOC_CREATE_QUEUE) after opening the AMDGPU render node; there is no network, adjacent-wireless, or physical-device path to the vulnerable kfd_queue_acquire_buffers() code.

AC:LAttack complexity, low

An attacker who can open /dev/kfd and map GPU buffers can reliably bypass the EOP size check with eop_buffer_size=0xFFFFF001 (32-bit ALIGN wraps to 0) and trigger CP EOP writes by submitting compute work on the created queue.

PR:LPrivileges required, low

Only a local unprivileged user with AMDGPU/KFD access (typically membership in the render group for /dev/dri/renderD* and /dev/kfd) is required; no real-root or init-namespace capabilities are needed.

UI:NUser interaction, none

No victim interaction is required; the attacker drives the full chain via their own KFD and DRM file descriptors, GPU memory mappings, and queue submission.

S:UScope, unchanged

The bug corrupts GPU virtual memory within the attacker's own process VMID and can fault or reset the shared GPU; it does not cross a VM/host, IOMMU, or sandbox security boundary into another authority.

C:HConfidentiality impact, high

CP hardware performs out-of-bounds EOP writes up to 8KB into a 4KB backing object, corrupting adjacent GPU-mapped memory that can be read back or chained into further memory disclosure primitives.

I:HIntegrity impact, high

The MQD is programmed with an 8KB EOP ring while only a 4KB buffer is validated, causing the GPU command processor to write attacker-triggered data past the buffer end into adjacent GPU mappings.

A:HAvailability impact, high

EOP writes beyond the undersized buffer cause GPU VM faults that can hang the device and schedule amdgpu_amdkfd_gpu_reset(), denying GPU service to all co-located workloads on shared cloud/HPC/desktop GPUs.