DF-4263 — duplicate CS chunks (BO_HANDLES / FENCE / SYNCOBJ_OUT) leak kernel refs

File: sys/dev/drm/amd/amdgpu/amdgpu_cs.c (pass 2) Severity: Medium (unprivileged local resource-exhaustion DoS) — CWE-401 Confidence: certain (static proof; leak arithmetic exact)

Build

cc -O2 -Wall -o dup_chunk_leak dup_chunk_leak.c

Run (as any user on amdgpu hardware)

./dup_chunk_leak

Creates one 1 MiB GTT BO, then submits 1000 CS ioctls whose chunk array holds two AMDGPU_CHUNK_ID_BO_HANDLES chunks, each listing the same handle 64 times. Every CS permanently leaks 64 amdgpu_bo references plus one whole amdgpu_bo_list (kref 1, never dropped). Repeat (or raise NENTRY/ROUNDS) until GTT/kernel-memory exhaustion.

Root cause (path:line)

• The chunk-dispatch loop amdgpu_cs_parser_init() (amdgpu_cs.c:151-222) never rejects a duplicate stateful chunk:
• BO_HANDLES (:200-211) → amdgpu_cs_bo_handles_chunk() (:78-101) → amdgpu_bo_list_create(..., &p->bo_list) assigns a new list (kref 1, holds one amdgpu_bo ref per entry — amdgpu_bo_list.c:83,103) over p->bo_list without dropping the previous one. amdgpu_cs_parser_fini() puts it exactly once (amdgpu_cs.c:807-808). First list + all its BO refs leak forever.
• FENCE (:186-198) → amdgpu_cs_user_fence_chunk() (:37-76) does amdgpu_bo_ref() then overwrites p->uf_entry.tv.bo (:52); fini unrefs once (:815-819) → one BO ref leaked per extra FENCE chunk.
• SYNCOBJ_OUT — amdgpu_cs_process_syncobj_out_dep() (:1138-1163) overwrites p->post_dep_syncobjs and resets num_post_dep_syncobjs = 0 (:1148-1151), leaking the previous array and every drm_syncobj reference it holds (drm_syncobj_find takes a ref — drm_syncobj.c:83-94); fini releases only the last array (:797-799).
• The ioctl-level guard that exists (amdgpu_cs.c:587-589) only rejects bo_list_handle+chunk, not chunk+chunk.

Reachability: AMDGPU_CS is DRM_AUTH|DRM_RENDER_ALLOW (`amdgpu_kms.c:1206). All chunk types need only well-formed ≥min-size kdata (FENCE ≥8B, BO_HANDLES ≥24B, SYNCOBJ_OUT ≥4B — enforced at :188/:202 and by floor-division at :1145-1146).

Guest verification (this audit)

Same hardware gate as DF-4262 (no AMD GPU → no /dev/dri): trigger builds (build.log), run exits at open (run.log); baseline + patched in-tree compile of amdgpu_cs.c both rc=0 with -Werror (kmod_baseline_build.log, fix_build.log).

Fix

fix.diff: reject duplicates — -EINVAL when p->uf_entry.tv.bo is already set (FENCE), when p->bo_list is already set (BO_HANDLES), and when p->post_dep_syncobjs is already allocated (SYNCOBJ_OUT).

DF-4263 evidence pack — verdict

Reproduced? NOT at runtime — hardware-gated (no AMD GPU on the audit guest, /dev/dri absent — env.txt/run.log). Defect: PROVEN at code level (certain): permanent, unbounded leak of kernel objects + BO references per CS ioctl, by an unprivileged render-node client.

Proof chain

1. BO_HANDLES (the heavyweight variant): a. amdgpu_cs_parser_init() loop (amdgpu_cs.c:151-222) dispatches every BO_HANDLES chunk (:200-211) to amdgpu_cs_bo_handles_chunk() with no duplicate guard. b. amdgpu_cs_bo_handles_chunk() (:78-101) calls amdgpu_bo_list_create(p->adev, p->filp, info, data->bo_number, &p->bo_list) — the list is stored via the out-param, replacing any previous value of p->bo_list without dropping it. c. amdgpu_bo_list_create() (amdgpu_bo_list.c:61-151) returns the list with kref_init = 1 (:83) and holds one amdgpu_bo_ref() per entry (:103). The only put that ever runs for it is amdgpu_cs_parser_fini() (amdgpu_cs.c:807-808, amdgpu_bo_list_put) — which fires exactly once, for the LAST list. The first list object (kmalloc'd, sizeof(list) + n*sizeof(entry)) and every BO reference it holds leak permanently. d. Rate: bo_number is user-chosen (bounded only by the kvmalloc in amdgpu_bo_list.c:226); the same GEM handle may appear many times. Each CS ioctl therefore leaks an attacker-chosen number of BO references (each BO ≥ PAGE_SIZE of GTT/VRAM + kernel structs) plus one list. GEM handles are created once and reused across CS calls, so N CS ioctls × M entries = N×M leaked refs with only M live BOs — unbounded exhaustion without allocating more GPU memory.
2. FENCE variant: amdgpu_cs_user_fence_chunk() (:37-76) takes amdgpu_bo_ref() (:50) and assigns p->uf_entry.tv.bo = &bo->tbo (:52). A second FENCE chunk overwrites the pointer; fini unrefs once (:815-819). Net +1 BO ref per extra FENCE chunk.
3. SYNCOBJ_OUT variant: amdgpu_cs_process_syncobj_out_dep() (:1138-1163) allocates a fresh p->post_dep_syncobjs array (:1148) and resets p->num_post_dep_syncobjs = 0 (:1151). A second SYNCOBJ_OUT chunk (the whole amdgpu_cs_dependencies() loop :1170-1188 processes every chunk) orphans the first array together with every drm_syncobj reference taken by drm_syncobj_find() (drm_syncobj.c:83-94 — the reference must be released with drm_syncobj_put; fini only puts the last array, amdgpu_cs.c:797-799).
4. The only existing duplicate guard (amdgpu_cs.c:587-589) rejects ioctl-arg bo_list_handle combined with a BO_HANDLES chunk — it does NOT protect chunk-vs-chunk duplication, which is what the PoC uses.

Guest verification performed

• trigger compiles (build.log); runs to the hardware gate (run.log)
• baseline amdgpu_cs.c in-tree compile rc=0 with -Werror (kmod_baseline_build.log)
• stacked fix (DF-4262+4263+4264+4265 diffs) applied via patch -p1 (hunks at 190/209/1155) and recompiled rc=0 with -Werror (fix_build.log) — fix compiles; runtime leak measurement needs HW.

Exploit chain: memory-exhaustion DoS only (no memory-safety violation: the leaked objects stay valid, they are simply never freed).

Recommended fix: reject duplicate stateful chunks (fix.diff).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.