# 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.