Description

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignment eop_ring_buffer_size in struct queue_properties is a u32. In kfd_queue_acquire_buffers() the expected EOP buffer size is computed as ALIGN(eop_ring_buffer_size, PAGE_SIZE); ALIGN uses typeof(x), so the addition is done in 32-bit. A user-supplied size of 0xFFFFF001 wraps to 0, causing kfd_queue_buffer_get() to skip its exact-size check (gated on size != 0) and accept any BO mapped at the address. On GFX8/GFX9 the MQD cp_hqd_eop_control is then programmed for an 8KB EOP ring backed by a 4KB BO, so CP EOP writes can land past the buffer and fault the GPU. Cast the operand to u64 so the alignment is computed in 64-bit; the size check in kfd_queue_buffer_get() then rejects the oversized request. (cherry picked from commit ae443117b742c357bfef3a7bddabf76fcf86e9ef)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:49.287Z",
  "pubdate": "2026-08-15T13:17:49.287Z",
  "executiveSummary": "An integer overflow vulnerability exists in the Linux kernel's AMDGPU driver within the amdkfd subsystem, specifically in the EOP ring buffer size alignment logic.\nThe vulnerability arises due to 32-bit arithmetic wrapping when computing the page-size alignment for the user-supplied eop_ring_buffer_size parameter.\nAn unprivileged local attacker with access to the AMD GPU device node can supply a specially crafted size value (such as 0xFFFFF001) that wraps to zero during alignment computation.\nThis arithmetic overflow bypasses exact-size validation checks in kfd_queue_buffer_get(), leading to a mismatch between the expected EOP ring buffer size and the allocated backing buffer object (BO).\nSuccessful exploitation allows Command Processor (CP) EOP writes to land past the boundaries of the allocated 4KB buffer on GFX8 and GFX9 hardware architectures.\nThe resulting out-of-bounds writes trigger a GPU memory fault, causing a denial of service or potentially leading to unstable system behavior.\nMitigation requires applying the official kernel patch that casts the buffer size operand to a 64-bit integer, ensuring that arithmetic operations and subsequent size checks execute correctly.",
  "technicalDetails": "The vulnerability resides in the Linux kernel amdkfd subsystem, specifically impacting queue management functions within the AMDGPU driver for GFX8 and GFX9 hardware architectures.\nThe root cause is an integer overflow occurring during the computation of the End-of-Pipe (EOP) ring buffer size. In struct queue_properties, eop_ring_buffer_size is defined as a 32-bit unsigned integer (u32).\nWithin the kfd_queue_acquire_buffers() function, the expected EOP buffer size is calculated using the ALIGN macro: ALIGN(eop_ring_buffer_size, PAGE_SIZE). Because the ALIGN macro utilizes the typeof(x) operator, the addition and alignment operations are performed entirely within 32-bit arithmetic space.\nWhen a local attacker supplies a malicious size value of 0xFFFFF001, the addition required for page alignment causes an integer overflow, wrapping the resulting value to 0.\nThis wrapped value of zero evades the security check in kfd_queue_buffer_get(), which relies on a size != 0 conditional gate to validate exact buffer sizes. Consequently, the function accepts any buffer object (BO) mapped at the specified address regardless of its actual dimensions.\nDuring subsequent execution phases on GFX8 and GFX9 architectures, the MQD register cp_hqd_eop_control is programmed to expect an 8KB EOP ring buffer, while the underlying BO is backed by only a 4KB allocation.\nBecause the Command Processor (CP) attempts to write EOP telemetry across an 8KB span into a 4KB backing store, hardware memory writes overflow past the legitimate buffer boundaries.\nThese out-of-bounds memory writes corrupt adjacent GPU memory structures and trigger an immediate GPU hardware fault, resulting in a denial of service.\nThe attack requires local execution capabilities and access to the AMDGPU device file descriptor, but does not necessitate advanced privileges beyond standard device node access."
}