• File: sys/dev/drm/amd/amdgpu/amdgpu_cs.c
• Lines: 59, 234, 742, 243
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
• CWE: CWE-190 Integer Overflow or Wraparound
• Confidence: certain

Summary

amdgpu_cs_user_fence_chunk validates (data->offset + 8) > size with the addition performed in 32-bit __u32 arithmetic. For data->offset in {0xFFFFFFF8..0xFFFFFFFF} the sum wraps to {0..7}, passes the check, and uf_offset is stored as the un-truncated large value.

The resulting job->uf_addr = uf_offset + amdgpu_bo_gpu_offset(uf) points ~4 GB past the PAGE_SIZE BO, and the GPU writes 8 bytes of fence sequence there during amdgpu_ib_schedule — an attacker-directed OOB write into VRAM/GTT/system memory.

Root cause

amdgpu_cs.c:58-62:

size = amdgpu_bo_size(bo);              /* unsigned long, = PAGE_SIZE (4096) */
if (size != PAGE_SIZE || (data->offset + 8) > size) {
    r = -EINVAL; goto error_unref;
}

data->offset is __u32 (uapi: drm_amdgpu_drm.h:588). data->offset + 8 is computed as unsigned int + int -> unsigned int (32-bit), so 0xFFFFFFF8 + 8 wraps to 0, then (unsigned long)0 > 4096UL is false.

uf_offset is then assigned the raw 0xFFFFFFF8 at line 69 (*offset = data->offset;).

In amdgpu_cs_parser_init:234 p->job->uf_addr = uf_offset; stores it as u64 (job->uf_addr is uint64_t, amdgpu_job.h:58).

In amdgpu_cs_parser_bos:742 p->job->uf_addr += amdgpu_bo_gpu_offset(uf); finalises it.

In amdgpu_ib.c:243-245 amdgpu_ring_emit_fence(ring, job->uf_addr, job->uf_sequence, ... | AMDGPU_FENCE_FLAG_64BIT) emits a GPU command that performs an 8-byte write at uf_addr with no further bounds validation (only a non-zero check at amdgpu_ib.c:243 and amdgpu_cs.c:1049).

Threat

Any unprivileged local user with access to a DRM render node (/dev/dri/renderD128, mode 0666 by default). No master/cap requirement.

The attacker:

1. amdgpu_bo_create with PAGE_SIZE,
2. amdgpu_cs with a CHUNK_ID_FENCE chunk whose data.offset is 0xFFFFFFF8 (or 0xFFFFFFF9..0xFFFFFFFF),
3. the IB executes and the GPU writes 8 bytes (the predictable per-context fence sequence, 1/2/3/...) at gpu_offset_of_uf + 0xFFFFFFF8.

The write lands ~4 GB past the uf BO in the GPU physical address space — inside another process's VRAM/GTT BO, the GTT aperture backing system memory, or empty VRAM (causing GPU fault/DoS).

Cross-process GPU buffer corruption is achievable; on configurations where the GTT aperture overlaps system RAM this can corrupt kernel-visible memory.

The 8-byte payload is not fully attacker-chosen but is predictable and controllable via submission ordering (seq counter).

Exploit / PoC

PoC sketch (libdrm-style ioctl, ~80 lines):

1. open("/dev/dri/renderD128", O_RDWR); drmGetCap(...AMDGPU_CHIP_IP_DMA...); amdgpu_device_initialize.
2. amdgpu_ctx_alloc -> ctx_id.
3. amdgpu_bo_alloc({.size = PAGE_SIZE, .domain = AMDGPU_GEM_DOMAIN_GTT}) -> uf_handle. (must be exactly PAGE_SIZE; check rejects any other size at amdgpu_cs.c:59.)
4. Build chunk array with two chunks: - CHUNK_ID_IB: {ip_type=AMDGPU_HW_IP_DMA, ip_instance=0, ring=0, ib_bytes=256, va_start=<mapped addr of a tiny cmd BO>, flags=0} - CHUNK_ID_FENCE: {handle=uf_handle, offset=0xFFFFFFF8} — the overflow
5. amdgpu_cs_submit2(ctx_id, &chunks); observe return 0 (check passes).
6. GPU executes IB; emits fence write at uf_addr = gpu_offset_of_uf + 0xFFFFFFF8.
7. Demonstrate impact: place a known-pattern victim BO at gpu_offset_of_uf + 0xFFFFFFC0 (by allocating many GTT BOs and querying their GPU offsets). After CS completes, mmap victim BO; observe the 8-byte fence-sequence value overwritten at byte offset 0x38 within the victim BO (i.e., at gpu_offset_of_uf + 0xFFFFFFF8). On dmesg, expect no error.

Successful reproduction: 8 bytes of victim BO corrupted with the sequence number.

Variants: pick offset so the write lands at the start of a page used by a different process's command buffer to escalate to arbitrary GPU command injection; or target VRAM-resident ring buffer metadata to cause GPU-wide DoS.

Build on DragonFlyBSD: cc -I/usr/local/include -ldr -o poc uf_overflow_poc.c; the binary uses pure ioctls so it can also build with cc -D_USERLAND_ONLY_ -o poc uf_overflow_poc.c using libdrm-amdgpu.

Recommended fix

Force the comparison into 64-bit. Replace the 32-bit addition with an explicit widening, OR (equivalently) re-express the bound to avoid arithmetic overflow.

--- a/sys/dev/drm/amd/amdgpu/amdgpu_cs.c
+++ b/sys/dev/drm/amd/amdgpu/amdgpu_cs.c
@@ -56,7 +56,7 @@ static int amdgpu_cs_user_fence_chunk(struct amdgpu_cs_parser *p,
    }

    size = amdgpu_bo_size(bo);
-   if (size != PAGE_SIZE || (data->offset + 8) > size) {
+   if (size != PAGE_SIZE || (uint64_t)data->offset + 8 > size) {
        r = -EINVAL;
        goto error_unref;
    }

Rationale: casting data->offset to uint64_t before the addition makes the sum 64-bit, so 0xFFFFFFF8 + 8 = 0x100000000 which is correctly > 4096, rejecting the malicious offsets.

Equivalent alternative: if (size != PAGE_SIZE || data->offset > size - 8).

Apply the same hardening in any sibling driver copy (radeon_cs.c, i915_gem_execbuffer.c) that uses the same pattern.

Related findings

• DF-1484 (sibling): IB chunk missing size validation in same file.