Summary

In amdgpu_benchmark_move(), the dobj pin-failure path unreserves sobj (which was already unreserved earlier) instead of dobj (which is currently reserved), leaving dobj locked. The subsequent cleanup then fails to re-reserve dobj and skips its unpin before unref, producing a reservation-object lock imbalance and a resource leak on the error path.

Root cause

• amdgpu_benchmark.c:114 reserves dobj (r = amdgpu_bo_reserve(dobj, false);).
• amdgpu_benchmark.c:117 pins dobj.
• The pin-failure block at amdgpu_benchmark.c:118-120 should release the reservation on dobj, but line 119 calls amdgpu_bo_unreserve(sobj); — a copy-paste from the analogous sobj path at amdgpu_benchmark.c:99-101. At this point sobj was already unreserved at amdgpu_benchmark.c:104, so this calls ttm_bo_unreserve() (amdgpu_object.h:165-168 → ttm_bo_unreserve) on a BO the caller does not hold, while dobj remains reserved.
• Then out_cleanup at amdgpu_benchmark.c:153 r = amdgpu_bo_reserve(dobj, true) attempts to re-reserve the already-self-held ww_mutex; with no_intr=true (ttm_bo_reserve non-interruptible, non-blocking attempt) it returns -EBUSY/-EDEADLK without waiting, so the if (likely(r == 0)) guard at amdgpu_benchmark.c:154 is false and amdgpu_bo_unpin(dobj) at line 155 is skipped; amdgpu_bo_unref(&dobj) at line 158 then runs on a still-locked, still-pinned BO.

Threat model & preconditions

• Attacker position: privileged — reachable only when the destination-BO pin fails during a benchmark (amdgpu_benchmarking tunable enabled, non-default) under VRAM/GTT pressure — same privileged-config precondition as DF-2119.
• Privileges gained or impact: reservation-object lock-state corruption (unlocking a BO not held, leaking the reservation on dobj) and a pinned-BO resource leak; worst observed outcome is a kernel warning/lockup or a ttm assertion on debug builds (availability). No confidentiality/integrity impact demonstrated; no path to memory corruption shown. Rated Low.
• Required config or capabilities: AMD GPU; amdgpu.benchmark set AND destination-domain pin failure induced (tiny VRAM aperture on a debug VM, or mocked/stubbed pin returning -ENOMEM).
• Reachability: amdgpu_benchmark_move() runs; dobj pin fails; line 119 unreserves sobj (already unlocked) and dobj stays locked.

Proof of Concept

Reproduce (logic/lock-imbalance proof, no privilege gain):

1. Enable amdgpu benchmark tunable as in DF-2119 (loader.conf amdgpu.benchmark=2 for the VRAM→VRAM case to exercise the dobj path, or any test_number) AND arrange for amdgpu_bo_pin(dobj, ddomain) at amdgpu_benchmark.c:117 to fail.
2. Boot / attach amdgpu. amdgpu_benchmark_move() runs; dobj pin fails; line 119 unreserves sobj (already unlocked) and dobj stays locked.
3. Observe in dmesg: a dev_err '%p reserve failed' from amdgpu_object.h:159 (the spurious unreserve of sobj may trip the ww_mutex non-held unlock assertion in LOCKDEBUG), AND the dobj pin leak / unpin-skip. On LOCKDEBUG/INVARIANTS kernels this is a direct panic/assertion; on production it is a silent resource leak.

No memory-corruption primitive; this is a correctness/lock-hygiene defect reported for completeness.

Impact

• Default config: not triggered (amdgpu.benchmark defaults to 0).
• Blast radius: lock imbalance + resource leak on privileged debug config.

Recommended fix

Unreserve the object that was actually reserved — dobj, not sobj.

--- a/sys/dev/drm/amd/amdgpu/amdgpu_benchmark.c
+++ b/sys/dev/drm/amd/amdgpu/amdgpu_benchmark.c
@@ -116,7 +116,7 @@ static void amdgpu_benchmark_move(struct amdgpu_device *adev, unsigned size,
    r = amdgpu_bo_pin(dobj, ddomain);
    if (r) {
-       amdgpu_bo_unreserve(sobj);
+       amdgpu_bo_unreserve(dobj);
        goto out_cleanup;
    }

This mirrors the correct sobj pin-failure handling at amdgpu_benchmark.c:99-101 and lets out_cleanup's amdgpu_bo_reserve(dobj, true) at line 153 succeed so unpin/unreserve/unref proceed normally.

References

• DF-2119 — sibling double-dma_fence_put in the same file.
• sys/dev/drm/amd/amdgpu/amdgpu_benchmark.c:99-101 — the correct sobj pin-failure pattern this should have mirrored.

Timeline

• 2026-07-25 Discovered during automated audit.
• 2026-07-25 Reported to DragonFlyBSD security contact.