Summary

reservation_object_get_fences_rcu, reservation_object_wait_timeout_rcu and reservation_object_test_signaled_rcu all rely on dma_fence_get_rcu() returning NULL when a fence is being torn down so the reader can retry under rcu_read_lock. The DragonFlyBSD dma_fence_get_rcu() shim unconditionally calls kref_get() (always succeeds) instead of kref_get_unless_zero(), so every if (!dma_fence_get_rcu(...)) goto retry check in this file is dead code and the reader keeps a reference on a fence whose refcount has already hit 0. The reader's eventual dma_fence_put() drives 1→0 a second time and re-fires dma_fence_release() → double-free. The shim's dma_fence_free() makes this far worse by calling kfree() instead of kfree_rcu().

Root cause

Primary defect: sys/dev/drm/include/linux/dma-fence.h:97-103:

static inline struct dma_fence *
dma_fence_get_rcu(struct dma_fence *fence)
{
    if (fence)
        kref_get(&fence->refcount);   /* always succeeds, even on refcount==0 */
    return fence;
}

Upstream Linux uses kref_get_unless_zero() here and returns NULL on a zero refcount. This tree already implements kref_get_unless_zero() correctly at sys/dev/drm/include/linux/kref.h:85-88, but dma_fence_get_rcu does not use it. As a result, every negated check in this file's RCU readers is dead code:

• linux_reservation.c:357 if (!dma_fence_get_rcu(fence_excl)) goto unlock;
• linux_reservation.c:384 if (!dma_fence_get_rcu(shared[i])) break;
• linux_reservation.c:444 if (!dma_fence_get_rcu(fence)) goto unlock_retry;
• linux_reservation.c:470 if (!dma_fence_get_rcu(lfence)) goto unlock_retry;
• linux_reservation.c:511 if (!fence) return -1;

Compounding defect: sys/dev/drm/linux_fence.c:339-343:

void dma_fence_free(struct dma_fence *fence) { kfree(fence); }

Upstream uses kfree_rcu(fence, rcu). The struct already carries an rcu field (dma-fence.h:45). Because the free is not deferred, a writer dropping the last fence ref synchronously frees the memory even when an rcu_read_lock reader is concurrently dereferencing the same pointer.

Lifecycle creating the racing drop: reservation_object_add_excl_fence (linux_reservation.c:235-261) installs the new fence under seqcount, then dma_fence_put(old_fence) at line 260. If that put drives old_fence->refcount to 0, dma_fence_release() fires → dma_fence_free() → kfree() at once.

Threat model & preconditions

• Attacker position: local unprivileged user with /dev/dri/cardN access (default mode 0666 on DFly desktops; radeon, amdgpu, and i915 drivers all wire the read paths to GEM ioctls).
• Privileges gained or impact: with slab grooming (spray objects the same size as the driver's dma_fence wrapper, e.g. amdgpu_fence, radeon_fence, i915_request), the second release is a controlled arbitrary write / type confusion → local unprivileged user → uid 0. Floor: deterministic panic (double kfree, slab freelist corruption).
• Required config or capabilities: device amdgpu / device radeon / device i915 with /dev/dri/card0 accessible.
• Reachability:
• Reader: amdgpu_gem_wait_idle_ioctl → reservation_object_wait_timeout_rcu (amdgpu_gem.c:445); radeon_gem_set_domain_ioctl → same (radeon_gem.c:117); i915_request_await_object → reservation_object_get_fences_rcu (i915_request.c:989).
• Writer (same DRM fd, racing thread): any execbuf/CS ioctl that ends in reservation_object_add_excl_fence (ttm_execbuf_util.c:206, amdgpu_object.c:1330, radeon_object.c:874).

Proof of concept

Two threads sharing a DRM fd: thread A submits CS continuously (installs fresh exclusive fences, dropping refs on old ones); thread B calls GEM_WAIT_IDLE continuously (reads the fence under rcu_read_lock via dma_fence_get_rcu). The race window between the writer's dma_fence_put(old) → kfree(old) and the reader's dma_fence_get_rcu(old) → kref_get on freed memory.

cc -O2 trigger.c -ldrm -lamdgpu -lpthread -o trigger
./trigger

Expected output

panic: kmem_free: ... not in list     # double kfree via the bad shim
OR
panic: Bad linked list                # slab freelist corruption
OR
silent heap corruption with slab grooming -> uid=0

Impact

High: unprivileged local-to-root UAF/double-free on default-config systems with any DRM driver (radeon/amdgpu/i915). The DMA-fence compat shim diverges from upstream Linux in two security-critical ways (kref_get instead of kref_get_unless_zero, kfree instead of kfree_rcu), defeating the RCU retry protocol that every reservation reader in this file depends on.

Recommended fix

Both compounding defects must be fixed in the DMA-fence compat shim:

(a) dma_fence_get_rcu must honor the "do not revive a dead object" contract:

--- a/sys/dev/drm/include/linux/dma-fence.h
+++ b/sys/dev/drm/include/linux/dma-fence.h
@@ -95,9 +95,12 @@ struct dma_fence *
 dma_fence_get_rcu(struct dma_fence *fence)
 {
+   /* Must NOT take a reference on a fence whose refcount is already 0. */
    if (fence)
-       kref_get(&fence->refcount);
+       if (!kref_get_unless_zero(&fence->refcount))
+           fence = NULL;
    return fence;
 }

(b) dma_fence_free must defer the free by one RCU grace period:

--- a/sys/dev/drm/linux_fence.c
+++ b/sys/dev/drm/linux_fence.c
@@ -339,6 +339,6 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout)
 void
 dma_fence_free(struct dma_fence *fence)
 {
-   kfree(fence);
+   kfree_rcu(fence, rcu);
 }

After both changes, the retry loops in this file behave as designed: a reader that loses the race observes dma_fence_get_rcu returning NULL and retries, never holding a reference on a fence being released.

References

• kref_get_unless_zero already available: kref.h:85-88.
• struct dma_fence.rcu field: dma-fence.h:45.
• Reservation reader paths: linux_reservation.c:357, 384, 444, 470, 511.

Timeline

• 2026-07-20 Discovered during automated audit.
• 2026-07-20 Reported to DragonFlyBSD security contact (pending).