DF-5131 — radeon_sync_resv()/radeon_sync_rings() returns discarded by 7 remaining callers (DF-4871 family completion)

File: sys/dev/drm/radeon/radeon_sync.c (pass 2) — findings live at the call sites enumerated below; the sync engine (radeon_sync.c:89-201) correctly returns the error, the callers drop it.

What this is

radeon_sync_resv() (radeon_sync.c:89-125) and radeon_sync_rings() (radeon_sync.c:137-201) return int precisely so a submitter can abort when a cross-ring dependency cannot be established (interrupted fence wait -ERESTARTSYS, semaphore SA-bo allocation -ENOMEM, radeon_ring_alloc() fence-wait failure, disabled source ring -EINVAL). Pass 1 already filed two of the offenders:

• DF-4871 — sys/dev/drm/radeon/r600_dma.c:466-467 (r600_copy_dma)
• DF-5089 — sys/dev/drm/radeon/si_dma.c:255-256 (si_copy_dma)

This pass found seven more call sites that discard the return, none covered by an existing finding (checked against findings for cik_sdma.c, r600.c, rv770_dma.c, evergreen_dma.c, cik.c, radeon_vm.c):

| # | Site | Function | What is dropped | |---|------|---------------------------| | 1 | sys/dev/drm/radeon/r600.c:2997-2998 | r600_copy_blit | resv + rings | | 2 | sys/dev/drm/radeon/cik.c:3695-3696 | cik_copy_blit | resv + rings | | 3 | sys/dev/drm/radeon/evergreen_dma.c:130-131 | evergreen_copy_dma | resv + rings | | 4 | sys/dev/drm/radeon/rv770_dma.c:66-67 | rv770_copy_dma | resv + rings | | 5 | sys/dev/drm/radeon/cik_sdma.c:601-602 | cik_copy_dma | resv + rings | | 6 | sys/dev/drm/radeon/radeon_vm.c:705 | radeon_vm_update_page_tables | resv (PD fence) | | 7 | sys/dev/drm/radeon/radeon_vm.c:833 | radeon_vm_update_ptes | resv — and r is immediately clobbered by the following reservation_object_reserve_shared() call, so the failure could never be observed even by accident |

All five copy sites hold rdev->ring_lock at the point of the call (so the sync engine's cross-ring radeon_ring_alloc() is serialized — not a locking bug), and all proceed to emit the copy/PT-update commands and commit the ring after the unchecked sync failure.

Impact

On any sync failure the DMA copy / blit / page-table update is submitted without the cross-ring dependency it exists to enforce:

• copy paths: silent stale-data bo corruption (the GPU reads the destination before the signaling ring finished writing it) — integrity impact;
• VM paths (6,7): page-table updates racing the fences on the PD/PT resv — GPU-visible memory-consistency violation, i.e. the GPU can walk page tables mid-update;
• the -ENOMEM / disabled-ring cases then also leak nothing (sync_free is still called on the success tail), but the ordering guarantee is silently gone.

Severity Low (family precedent DF-4871/DF-5089): hardware-gated to radeon GPUs, needs a sync failure to coincide with a cross-ring dependency — but the code path is certain, static, and trivially fixed.

Reproduce (static)

./check_static.sh

enumerates every radeon_sync_resv/radeon_sync_rings call in sys/dev/drm/radeon/ and classifies checked vs bare — expect exactly the 7 sites above reported BARE (plus the 2 known DF-4871/DF-5089 sites), and radeon_ib.c:149 / radeon_cs.c:256 reported CHECKED.

Runtime reproduction requires a physical radeon GPU with ≥2 initialized rings plus an induced radeon_sync_rings() failure (e.g. signal-pending dma_fence_wait); the QEMU audit guest has no AMD GPU (pciconf shows none), so no runtime PoC is possible on it — see VERDICT.md.

Fix

fix.diff — check both returns at all 7 sites with the canonical rollback (radeon_ring_unlock_undo() + radeon_sync_free() + ERR_PTR(r) for the copy paths; propagate r for the two VM sites, un-clobbering the variable at radeon_vm.c:833).

DF-5131 — VERDICT

status: untested (statically certain / runtime not testable on audit guest) reproduced: 0 · impact: none (demonstrable only as silent data-ordering loss on real radeon HW)

What was verified, and how

This is a pure static-contract defect: seven call sites invoke radeon_sync_resv() / radeon_sync_rings() as bare statements and proceed to emit + commit GPU work regardless of the returned error. The engine side (sys/dev/drm/radeon/radeon_sync.c:89-125, 137-201) is correct:

• radeon_sync_resv returns the dma_fence_wait() result on both the exclusive (radeon_sync.c:106) and shared (radeon_sync.c:119-122) paths;
• radeon_sync_rings returns -EINVAL (disabled source ring, radeon_sync.c:153-156), the radeon_fence_wait() failure (radeon_sync.c:160-163, 180-183, 190-193), radeon_semaphore_create() failure (radeon_sync.c:165-167) and radeon_ring_alloc() failure (radeon_sync.c:172-174).

The callers drop it. check_static.sh (this pack, run against the read-only sys/ tree, output in check_static.log) mechanically confirms:

• BARE (defective): r600.c:2997, cik.c:3695, evergreen_dma.c:130, rv770_dma.c:66, cik_sdma.c:601, radeon_vm.c:705, radeon_vm.c:833 (+ the already-filed r600_dma.c:466 / si_dma.c:255 = DF-4871/DF-5089);
• CHECKED (correct): radeon_ib.c:149 (r = radeon_sync_rings(...) with rollback), radeon_cs.c:256 (r = radeon_sync_resv(...) propagated).

Why no runtime PoC

1. The QEMU audit guest (DragonFly 6.5-DEVELOPMENT x86_64, uname in verdict.json) has no AMD/ATI PCI device (pciconf -l | grep -ic 'ati|amd|1002' → 0), so neither radeon nor amdgpu can attach; the code cannot execute.
2. Even on hardware, the observable is silent loss of GPU execution ordering (a stale-data race), not a crash: triggering needs a sync failure (-ERESTARTSYS on a signal-pending fence wait, -ENOMEM in radeon_semaphore_create, or a radeon_ring_alloc() fence-drain failure) to coincide with a cross-ring dependency on a bo the process can observe. That is a real but probabilistic corruption window — exactly why DF-4871 and DF-5089 were also filed Low on static certainty.

Per the pass-2 contract this is a Low finding outside the mandatory-verify buckets (not hammer2/memcorrupt/privesc, not Critical/High, not a trivially runnable local program) → verification honestly recorded as untested, with the machine-checkable static proof attached instead of a fabricated runtime claim.

Exploit chain

(none — GPU-internal ordering loss; worst case silent bo data corruption or a racing page-table update on radeon hardware)

Fix validation

Not applicable (no runtime baseline exists without hardware). fix.diff was authored after the static verification above: identical rollback pattern to the one radeon_ib_schedule() already uses for the same call (sys/dev/drm/radeon/radeon_ib.c:149-155). It applies cleanly to the unmodified tree (git apply --check verified) but was intentionally not applied to sys/.

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.