DF-4501 — radeon_uvd_send_msg() NULL-deref panic when radeon_ib_schedule() fails

Root cause

sys/dev/drm/radeon/radeon_uvd.c:763-766:

r = radeon_ib_schedule(rdev, &ib, NULL, false);

if (fence)
        *fence = radeon_fence_ref(ib.fence);

radeon_ib_get() sets ib->fence = NULL (sys/dev/drm/radeon/radeon_ib.c, "ib->fence = NULL;"). Every error return of radeon_ib_schedule() (sys/dev/drm/radeon/radeon_ib.c:122-181: !ring->ready, radeon_ring_lock failure, radeon_sync_rings failure, radeon_fence_emit failure) happens BEFORE radeon_fence_emit() assigns ib->fence — on failure ib.fence is still NULL.

radeon_fence_ref(NULL) (sys/dev/drm/radeon/radeon_fence.c:699) executes dma_fence_get(&fence->base). With fence == NULL the expression &fence->base evaluates to the small constant offsetof(struct radeon_fence, base) — a NON-NULL address — so dma_fence_get()'s if (fence) guard (sys/dev/drm/include/linux/dma-fence.h:90-95) PASSES and kref_get() performs an atomic increment at a near-NULL kernel address → kernel panic (write to low canonical kernel memory).

Trigger chain (no-rollback precondition)

1. radeon_uvd_cs_msg() allocates a UVD handle at CS parse time (radeon_uvd.c:522-526: atomic_cmpxchg(&handles[i], 0, handle) + filp[i] = p->filp). Nothing rolls this back when the ioctl's later radeon_ib_schedule() fails.
2. Preconditions where the UVD ring cannot schedule while the UVD object/handles exist: UVD ring failed to come up (ring->ready false, e.g. firmware/startup failure after radeon_uvd_init() allocated the vcpu_bo), GPU reset/teardown windows, or ring lock pressure.
3. User submits one create-msg CS → error returned, handle stays.
4. User closes the DRM fd → postclose → radeon_uvd_free_handles() (radeon_uvd.c:328-352) sees handle != 0 → radeon_uvd_get_destroy_msg() (radeon_uvd.c:813) → radeon_uvd_send_msg() → radeon_ib_schedule() fails again → radeon_fence_ref(NULL) → panic.

The same crash is reachable via radeon_uvd_suspend() (radeon_uvd.c:249) and the uvd_v1_0.c call sites, all of which pass &fence unconditionally.

Build / run

cc -O2 -Wall -o uvd_sendmsg_nullfence uvd_sendmsg_nullfence.c
./uvd_sendmsg_nullfence /dev/dri/card0

The userspace half (create handle via raw CS ioctls, ignore the error, close fd) is in uvd_sendmsg_nullfence.c; the kernel-side precondition (dead UVD ring) can be forced deterministically with fault-injection.diff (force radeon_ib_schedule to return -EINVAL in send_msg's path) on any radeon+UVD box: with injection → immediate panic at fd close; without → normal operation. This guest has no radeon hardware (env.txt), so the fault-injection run could not be executed here.

VERDICT — DF-4501

finding_id : DF-4501 status : untested (hardware-gated: needs a radeon ASIC with UVD; guest has no /dev/dri at all — env.txt) reproduced : 0 impact : none demonstrated (expected on hardware: panic — near-NULL kernel write from kref_get under dma_fence_get) confidence : likely

Mechanism, verified line-by-line

• radeon_uvd.c:740-770 radeon_uvd_send_msg(): after r = radeon_ib_schedule(rdev, &ib, NULL, false); the code does if (fence) *fence = radeon_fence_ref(ib.fence); — the guard tests the caller's out-param, not ib.fence.
• radeon_ib.c radeon_ib_get(): ib->fence = NULL; (initial state).
• radeon_ib.c radeon_ib_schedule(): all four error returns (!ib->length_dw || !ring->ready, radeon_ring_lock fail, radeon_sync_rings fail, radeon_fence_emit fail) precede the single success-path assignment of ib->fence by radeon_fence_emit. On any of them ib.fence is NULL when send_msg dereferences it.
• radeon_fence.c:699 radeon_fence_ref(): dma_fence_get(&fence->base); — with fence==NULL, &fence->base is the constant offsetof(struct radeon_fence, base) (small, NON-NULL), so dma-fence.h:90-95 if (fence) kref_get(&fence->refcount); takes the true branch and atomically increments a near-NULL address → kernel panic (low-address write fault in kernel mode).
• Callers that always pass &fence: radeon_uvd.c:263-264 (radeon_uvd_suspend), radeon_uvd.c:338-339 (radeon_uvd_free_handles, invoked from drm postclose), radeon_uvd.c:808/837 via get_create/destroy_msg, plus uvd_v1_0.c call sites.
• Why a handle can exist while the ring is dead: radeon_uvd.c:522-526 allocates handles at CS parse time; radeon's CS ioctl has no UVD-handle rollback on the later ib_schedule failure.

Why untested on this guest

Guest is QEMU std-VGA DragonFly 6.5-DEVELOPMENT with no /dev/dri (env.txt); the radeon ioctl surface and the UVD ring do not exist. Compile check of the userspace trigger only (build.log). Deterministic on-hw validation path is documented in fault-injection.diff (NOT applied to sys/): force radeon_ib_schedule failure inside send_msg, run ./uvd_sendmsg_nullfence, expect immediate near-NULL panic at fd close; baseline without injection runs clean.

Fix (fix.diff, git-apply-verified)

-   if (fence)
-       *fence = radeon_fence_ref(ib.fence);
+   if (!r && fence)
+       *fence = radeon_fence_ref(ib.fence);

Only hand out a fence when the IB actually scheduled. (Belt-and-braces: make radeon_fence_ref() NULL-safe like its dma_fence counterpart.)

fix_status: not_testable (no radeon hardware in the audit guest).

kernel_refs

sys/dev/drm/radeon/radeon_uvd.c:740-770 (unguarded ib.fence use) sys/dev/drm/radeon/radeon_uvd.c:263,338,808,837 (callers passing &fence) sys/dev/drm/radeon/radeon_uvd.c:522-526 (handle alloc at parse time) sys/dev/drm/radeon/radeon_ib.c (ib_get: fence=NULL; schedule error paths) sys/dev/drm/radeon/radeon_fence.c:699 (ref without NULL check) sys/dev/drm/include/linux/dma-fence.h:89-95 (guard defeated by &NULL->base)

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.