DF-4604 PoC — radeon_gem_va_ioctl bo_va UAF

What this is

A minimal, self-contained trigger for the bo_va use-after-free in radeon_gem_va_ioctl() (sys/dev/drm/radeon/radeon_gem.c:702). Two threads on the same DRM fd: A loops {GEM_CREATE → VA_MAP → VA_UNMAP}, B races GEM_CLOSE on the same handle, armed so that B is already blocked on the BO reservation at the moment A's radeon_vm_bo_set_addr() internally drops it.

Build

./build.sh            # cc -O2 -Wall -pthread -o radeon_va_uaf radeon_va_uaf.c

No drm headers required (UAPI vendored, BSD 3-arg _IOWR encoding matching sys/dev/drm/include/uapi/drm/drm.h:796-801).

Run (requires real radeon hardware, Cayman/HD69xx or newer)

./run.sh [/dev/dri/card0] [iterations]

Expected (unpatched kernel): kernel panic / drm fault in ttm_eu_reserve_buffers, mutex_lock, or radeon_vm_bo_update within seconds-to-minutes of iterations; with slab grooming, exploitable to uid=0 (see VERDICT.md).

On the audit QEMU guest: there is no radeon GPU; the binary builds and runs, printing SKIP: no DRM device… and exiting rc=3 (see run.log). This is the expected guest outcome — runtime confirmation needs a physical Cayman+ machine.

Patched kernel

With fix.diff applied (bo_va re-looked-up under the re-established reservation), the race window is closed; the trigger must run indefinitely without corrupting memory.

Files

• radeon_va_uaf.c — trigger source
• build.sh / run.sh — exact commands
• build.log / run.log — guest output (full, untrimmed)
• env.txt — guest environment
• VERDICT.md — full narrative with path:line proof
• fix.diff — validated-by-review unified fix
• manifest.json, verdict.json

DF-4604 — radeon_gem_va_ioctl() use-after-free on bo_va (GEM_VA vs GEM_CLOSE race)

• File: sys/dev/drm/radeon/radeon_gem.c
• Class: kernel heap UAF / type confusion (memcorrupt bucket)
• Severity: High — local unprivileged user with DRM access on Cayman-or-newer radeon
• Status: source-proven; runtime verification impossible on the audit guest (no radeon GPU — QEMU cannot emulate AMD GPUs)

TL;DR

radeon_gem_va_ioctl() finds bo_va under the BO reservation, then calls radeon_vm_bo_set_addr(), which drops the reservation internally, and only afterwards uses bo_va in radeon_gem_va_update_vm() — with no reservation and no vm->mutex protecting the first dereferences. A concurrent DRM_IOCTL_GEM_CLOSE (or close(2) of a dup'd fd) on the same file_priv runs radeon_gem_object_close() → radeon_vm_bo_rmv() → kfree(bo_va). Thread A then executes radeon_gem_va_update_vm() on the freed ~128-byte object: bo_va->bo, bo_va->vm, mutex_lock(&bo_va->vm->mutex), and radeon_vm_bo_update() on freed (reclaimable) memory.

The exact interleaving

Thread A: DRM_IOCTL_RADEON_GEM_VA (UNMAP)        Thread B: DRM_IOCTL_GEM_CLOSE (same fd!)
------------------------------------------------ ------------------------------------------
radeon_gem.c:665  drm_gem_object_lookup()         (gobj ref held by A — bo itself safe)
radeon_gem.c:671  radeon_bo_reserve(rbo)          → blocks here: rbo reserved by A
radeon_gem.c:677  bo_va = radeon_vm_bo_find()     |  (lifetime of bo_va is guaranteed ONLY
                  |                                |   by the BO reservation — see
                  |                                |   radeon_vm.c:117 "Object has to be
                  |                                |   reserved!")
radeon_gem.c:696  radeon_vm_bo_set_addr(0,0)      |
  radeon_vm.c:538 radeon_bo_unreserve() ------+   |
                  |                           |   +-- wakes, acquires reservation
                  |   *** WINDOW OPEN ***    +----→ radeon_gem.c:193 reserve OK
radeon_gem.c:702  radeon_gem_va_update_vm(bo_va)      radeon_gem.c:199 bo_va = find()
  radeon_gem.c:565   tv.bo = &bo_va->bo->tbo          radeon_gem.c:201 --ref_count==0
  radeon_gem.c:569   radeon_vm_get_bos(bo_va->vm,..)  radeon_gem.c:202 radeon_vm_bo_rmv()
  radeon_gem.c:573   ttm_eu_reserve_buffers()           radeon_vm.c:1127 it.start==0
  radeon_gem.c:585   mutex_lock(&bo_va->vm->mutex)      radeon_vm.c:1137 kfree(bo_va) ←FREE
  radeon_gem.c:590   if (bo_va->it.start)                 |
  radeon_gem.c:591   radeon_vm_bo_update(rdev, bo_va,..) |  ← ALL UAF

For the UNMAP variant the free is immediate (it.start == 0 → straight kfree). For the MAP variant, radeon_vm_bo_rmv() queues bo_va itself on vm->freed and thread A's own radeon_gem_va_update_vm() calls radeon_vm_clear_freed() (radeon_gem.c:586), which does kfree(bo_va) (radeon_vm.c:1065) and then A dereferences it at radeon_gem.c:590-591. Both variants UAF.

Why the race is practically hittable

Thread B blocks inside radeon_bo_reserve(rbo, true) while A holds the reservation during set_addr(). The instant set_addr internally unreserves, the already-blocked B is woken and runs its entire close path (find → rmv → kfree) while A is still returning from set_addr — the window is scheduler latency wide, not instruction width. Looping {GEM_CREATE → VA_MAP → (UNMAP ∥ GEM_CLOSE)} tens of thousands of times (see radeon_va_uaf.c) is sufficient on real hardware.

Preconditions

• radeon KMS hardware, family >= CHIP_CAYMAN, accel_working (gates both vm_manager.enabled at radeon_gem.c:618 and the close path at radeon_gem.c:188). Cayman (HD 69xx) through the last radeon-supported SI/CIK parts.
• An authenticated DRM fd (render node access as an unprivileged user, or any fd handed out by the display manager) — the ioctls are DRM_AUTH|DRM_RENDER_ALLOW (radeon_kms.c:912,918).
• Both threads on the same fd (or dup'd fds — same file_priv, same vm).

Exploitability sketch (primary objective: uid=0)

struct radeon_bo_va is ~96-104 bytes → kzalloc 128-size class. After the free, thread A's radeon_gem_va_update_vm(): 1. reads bo_va->bo and bo_va->vm from reclaimed memory, 2. passes &bo_va->bo->tbo into ttm_eu_reserve_buffers() (ww-mutex lock chains over attacker-influenced pointers), 3. mutex_lock(&bo_va->vm->mutex) on a reclaimed pointer, 4. radeon_vm_bo_update(rdev, bo_va, ...) walks bo_va->vm->page_tables[] and emits GPU page-table writes per the reclaimed vm.

Grooming the 128-byte slab with a kernel object whose contents the attacker controls (classic: repeated small kzalloc user-trigerable objects) converts step 4 into "point GPU PTEs at chosen physical pages", which on this intentionally-unhardened target (no SMAP/SMEP/KASLR equivalents for the GPU path) is a direct route to arbitrary physical read/write from the GPU command processor → uid=0. Even without full grooming, the immediate symptom on real hardware is a kernel panic in the reservation/mutex machinery.

Verification on the audit guest — honest classification

• Guest: DragonFly 6.5-DEVELOPMENT x86_64, QEMU std/Bochs VGA (chip=0x11111234). No /dev/dri, no radeon device, no drm in the kernel config. QEMU has no AMD-GPU emulation; the ioctl table for radeon never registers.
• The trigger (radeon_va_uaf.c) builds cleanly on the guest (build.log) and runs, exiting rc=3 with the documented SKIP (run.log).
• Therefore: status=inconclusive, reproduced=0 — the bug is proven by code trace (every step cited), but cannot be executed on this guest. Runtime confirmation requires a physical Cayman-or-newer machine. Fix validation likewise not_testable here.

Recommended fix

Re-look-up bo_va after ttm_eu_reserve_buffers() has re-established the BO reservation inside radeon_gem_va_update_vm() (and derive bo/vm from refcounted objects held by the ioctl). See 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.