• File: sys/dev/drm/amd/amdgpu/amdgpu_cs.c
• Lines: 166, 169, 175, 181, 182, 183, 184, 999, 1004, 1017, 1040, 1041
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
• CWE: CWE-125 Out-of-bounds Read
• Confidence: likely

Summary

amdgpu_cs_parser_init validates that length_dw is large enough for FENCE chunks (line 188) and BO_HANDLES chunks (line 202), but the AMDGPU_CHUNK_ID_IB case at lines 181–184 only increments num_ibs without any size check. A user can submit an IB chunk with length_dw as small as 1 (4-byte kdata buffer). amdgpu_cs_ib_fill then casts kdata to (struct drm_amdgpu_cs_chunk_ib *) and reads fields at offsets up to 28 from a 4-byte allocation, causing heap OOB reads of up to 28 bytes from adjacent slab objects.

Root cause

amdgpu_cs.c:181-184:

case AMDGPU_CHUNK_ID_IB:
    ++num_ibs;
    break;

No length_dw * sizeof(uint32_t) < sizeof(struct drm_amdgpu_cs_chunk_ib) check, unlike the FENCE (line 188) and BO_HANDLES (line 202) cases.

The chunk's kdata is allocated as kvmalloc_array(size, sizeof(uint32_t), GFP_KERNEL) at line 169 with size=length_dw, and length_dw*4 bytes are copied at line 176.

Then amdgpu_cs_ib_fill:999 does chunk_ib = (struct drm_amdgpu_cs_chunk_ib *)chunk->kdata; and reads chunk_ib->ip_type (offset 20), ip_instance (offset 24), ring (offset 28), flags (offset 4), va_start (offset 8), ib_bytes (offset 16) — all OOB when length_dw < 8. The struct drm_amdgpu_cs_chunk_ib (uapi: drm_amdgpu_drm.h:562-576) is 32 bytes = 8 dwords.

There is a secondary issue: line 175 size *= sizeof(uint32_t) truncates the byte count to 32-bit unsigned, so for length_dw = 0x40000000 (if the 4 GB kvmalloc somehow succeeds) copy_from_user copies 0 bytes, leaving the entire buffer as uninitialized kvmalloc memory that is then read as chunk_ib fields.

Threat

Any unprivileged local user via /dev/dri/renderDXX.

Submit amdgpu_cs with one IB chunk whose length_dw is 1..7. The OOB read of up to 28 bytes of adjacent kernel heap is consumed as IB control fields:

• ip_type/ip_instance/ring feed amdgpu_ctx_get_entity (which validates them — random values are usually rejected with -EINVAL, blocking further progress);
• ib_bytes drives amdgpu_ib_get SA allocation size for parse_cs rings (UVD/VCE) — random huge value typically fails allocation.

No direct path returns the read bytes to userspace, so this is primarily a kernel-hardening defect with possible DoS via huge SA-allocation attempts and theoretical info-leak under slab grooming.

Upstream Linux added this check (modern amdgpu_cs.c has if (size < sizeof(struct drm_amdgpu_cs_chunk_ib)) return -EINVAL; in the IB case); DragonFly is missing it.

Exploit / PoC

PoC: open render node, alloc ctx, alloc a 1-dword IB chunk (length_dw=1, chunk_data=any u32), alloc a deps chunk, submit CS.

Kernel OOB-reads chunk_ib->{flags, va_start, ib_bytes, ip_type, ip_instance, ring} from the 4-byte kmalloc(4) slab object plus the following 24+ bytes of adjacent slab.

With KASAN enabled the access is flagged immediately; without KASAN the random adjacent bytes usually fail ctx_get_entity validation → -EINVAL returned to user.

To demonstrate heap info disclosure: groom the slab (spray kmalloc-32 objects containing a marker pattern via amdgpu_bo userptr), submit the tiny IB chunk, observe whether the CS proceeds past amdgpu_ctx_get_entity (indicates the leaked ip_type/instance/ring happened to be valid).

The PoC materialises as: compile a libdrm C program that opens renderD128, calls AMDGPU_CTX_OP_ALLOC_CTX, then DRM_IOCTL_AMDGPU_CS with chunks=[{IB, length_dw=1, chunk_data=&(u32){0}}].

Build:

cc -ldr -I/usr/local/include/libdrm -o ib_oob_poc ib_oob_poc.c

Success = no -EINVAL before reaching amdgpu_cs_ib_fill's entity check (proves the OOB read occurred) plus KASAN/UMA zone report showing read past allocation.

Recommended fix

Add an explicit size check in the IB case, mirroring what FENCE/BO_HANDLES already do.

--- a/sys/dev/drm/amd/amdgpu/amdgpu_cs.c
+++ b/sys/dev/drm/amd/amdgpu/amdgpu_cs.c
@@ -179,6 +179,11 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
        switch (p->chunks[i].chunk_id) {
        case AMDGPU_CHUNK_ID_IB:
+           if (p->chunks[i].length_dw * sizeof(uint32_t)
+               < sizeof(struct drm_amdgpu_cs_chunk_ib)) {
+               ret = -EINVAL;
+               goto free_partial_kdata;
+           }
            ++num_ibs;
            break;

Additionally, harden the byte-count computation at line 175 against the size *= sizeof(uint32_t) 32-bit truncation: declare size_t bytes = (size_t)p->chunks[i].length_dw * sizeof(uint32_t); and pass bytes to both kvmalloc_array's effective byte count and copy_from_user. (kvmalloc_array already takes count+elem separately and rejects count*size_t overflow, so the alloc is fine; only the local unsigned size truncation is buggy.)

Related findings

• DF-1483 (sibling): user-fence offset integer overflow in same file.