DF-4871 — r600_copy_dma ignores radeon_sync_resv()/radeon_sync_rings() failures

File: sys/dev/drm/radeon/r600_dma.c (pass 2, GLM 5.3) Severity: Low · CWE-754 (Improper Check for Unusual or Exceptional Conditions)

What

r600_copy_dma() — the ttm/GEM buffer-object migration copy engine used by unprivileged GEM clients via radeon_bo_move → radeon_move_blit → radeon_copy(rdev, ..., bo->resv) (radeon_ttm.c:302) — discards both synchronization return values:

466:    radeon_sync_resv(rdev, &sync, resv, false);   /* int return ignored */
467:    radeon_sync_rings(rdev, &sync, ring->idx);    /* int return ignored */

radeon_sync_rings() (radeon_sync.c:137-201) can fail with -EINVAL ("Syncing to a disabled ring!", radeon_sync.c:153-156), fence-wait interruption (radeon_sync.c:160-163, 180-183, 190-193), or semaphore/alloc failure (radeon_sync.c:165-174). radeon_sync_resv() can fail on dma_fence_wait() errors (radeon_sync.c:106, 119). On any of these the function returns early — possibly after committing semaphore signals on other rings — and the pending cross-ring dependencies are not waited on; r600_copy_dma then emits the DMA copy packets and commits anyway.

Consequence: the copy can execute before a pending write to the same buffer object on another ring completes → silent GPU-side data corruption of the migrated bo (stale/partial source contents land in the destination). This is data corruption of the buffer's own contents, not kernel memory corruption.

Contrast with sibling code (why this is a defect, not a style choice)

• radeon_ib_schedule() — the other user of radeon_sync_rings() — checks the return and unwinds: radeon_ib.c:149-154 (failed to sync rings → radeon_ring_unlock_undo + return).
• Upstream Linux moved radeon_sync_resv() before the ring lock with full error handling (if (r) goto error_free;) in this exact function and reserves num_loops * 4 + 16 — this tree both ignores the errors and keeps the smaller + 8 reservation (the reservation half of that is the known DF-1943; the ignored-return half is this finding).

Siblings carrying the identical ignored-return pattern (cross-ref)

• sys/dev/drm/radeon/evergreen_dma.c:130-131
• sys/dev/drm/radeon/rv770_dma.c:66-67
• sys/dev/drm/radeon/si_dma.c:255-256
• sys/dev/drm/radeon/r600.c:2997-2998 (blit copy path)

Trigger / preconditions

Unprivileged GEM client causes bo migrations (VRAM↔GTT moves, eviction) whose resv carries fences on another ring; combined with a GPU state where radeon_sync_rings() fails (e.g. a ring disabled by a previous failed ib test/reset: ring->ready = false in radeon_ib.c:271 — then any pending fence on it makes sync_rings return -EINVAL). Realistically requires a r6xx+ GPU in a degraded state; deterministic construction is not possible from userland alone.

Verdict

Not runtime-verified: requires real r6xx-class Radeon hardware; the audit QEMU guest has none (see env.txt). Code-evident divergence from the checked sibling path. Status: untested (hardware-gated), confidence likely.

Fix

See fix.diff — check both returns, unwind ring lock and sync state on failure; radeon_sync_resv() is additionally moved before radeon_ring_lock() so its potentially-sleeping fence waits do not happen under the global rdev->ring_lock mutex (mirrors upstream).

DF-4871 VERDICT — r600_copy_dma ignores sync_resv/sync_rings failures

Bottom line

Not reproduced on the audit guest: triggering requires real r6xx-class Radeon hardware (the DMA copy engine) in a state where cross-ring synchronization fails while a bo migration is in flight — the guest has no Radeon hardware (env.txt). The defect is evident from source and from the divergence with the checked sibling path; impact ceiling is silent GPU-side data corruption of the migrated buffer object's own contents (I:L, no kernel memory corruption).

Why the code path is real (line-by-line trace)

1. Unprivileged GEM clients cause bo moves constantly (VRAM↔GTT migration, eviction under memory pressure): radeon_ttm.c radeon_bo_move → radeon_move_blit → radeon_ttm.c:302 radeon_copy(rdev, ..., bo->resv) → asic copy.copy = r600_copy_dma (registered e.g. radeon_asic.c for R600..NI DMA rings). resv is always the embedded &bo->tbo.resv (never NULL on this path — the Linux NULL-resv crash class does not apply here).
2. r600_dma.c:466 radeon_sync_resv(rdev, &sync, resv, false); — return value discarded. radeon_sync.c:106/119: on a non-radeon fence it does dma_fence_wait(); an interrupted wait returns an error and the sync is incomplete — ignored here.
3. r600_dma.c:467 radeon_sync_rings(rdev, &sync, ring->idx); — return value discarded. Failure modes (radeon_sync.c): - :153-156 -EINVAL "Syncing to a disabled ring!" — reachable when a source ring was disabled by an earlier failed ib test (radeon_ib.c:271 ring->ready = false) or GPU reset while fences on it are still pending; - :160-163 / :180-183 / :190-193 manual radeon_fence_wait() fallback errors; - :165-174 semaphore create / ring alloc failures. On the -EINVAL path the loop aborts before waiting on the remaining sync_to[] fences.
4. r600_dma.c:469-481, 490: the copy packets are emitted and radeon_ring_unlock_commit() fires regardless → the DMA copy is not ordered after the pending write on the other ring → the destination bo receives stale/partial source data, with a successfully-signaled fence. Silent, undetectable-from-userspace data corruption of the client's own buffer.
5. Contrast: radeon_ib.c:149-154 — the only other caller of radeon_sync_rings() — treats failure as fatal (unlock_undo + return). Upstream Linux additionally checks radeon_sync_resv() in this exact function (if (r) goto error_free;) and moved it before the ring lock.

Why it is not the known DF-1942/DF-1943

DF-1942 = size_in_dw wrap (copy length math); DF-1943 = insufficient ring dword reservation (num_loops * 4 + 8). This finding is the ignored error returns of the two sync calls — orthogonal defect, orthogonal fix (which DF-1943's reservation bump does not repair).

Exploit chain

None: no kernel memory is corrupted; corruption is confined to the bo's own GPU contents. A determined unprivileged user on degraded hardware could corrupt its own buffers' contents (not another user's — the missing sync is only w.r.t. fences on the same resv).

Fix validation

Not possible on this guest (no hardware). fix.diff authored from the trace above: check both returns; unwind (unlock_undo + sync_free) on failure; move radeon_sync_resv() before radeon_ring_lock() so its sleeping fence waits don't run under the global ring mutex — mirroring upstream. fix_status: not_testable.

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.