DF-2214 — 32-bit wrap in rv770_copy_dma DMA copy size silently truncates TTM buffer moves

Status: REPRODUCED (verbatim-code KLD rig) — impact class: GPU-side memory integrity (silent data corruption of video/GTT buffers). No host kernel memory corruption, no privilege-escalation primitive (verified — see VERDICT.md). Fix: A/B-validated in the same KLD (fix.diff, u64 widening identical in shape to the verified evergreen/si fix).

What this pack contains

How to reproduce

On the DragonFly guest (root, /usr/src present):

./build.sh   # rebuilds everything from the tree file; aborts on any hash mismatch
./run.sh     # kldloads the rig; prints the 16-case matrix to dmesg

Provenance (checked at build time, build aborts otherwise)

1. guest tree file sha256 = b33101a3cce7eba62ac2d1dda4e1ec0f7225028942cdbb1cafd1c9a2670e33d9 == audited sys/ tree file.
2. verbatim function = lines 42..94 == pattern extraction, pinned at sha256 = c1b2d82ab166f9e04f7158a8d6fe0506d22ee1c6f05aca121ca0ac9b5a6b547c.
3. fixed variant = fix.diff mechanically applied to those same bytes.

Expected output (baseline = unmodified production code)

DF2214 CASE variant=BASELINE pages=0x00100000 ...      # num_gpu_pages = 2^20
DF2214   num_loops=0 copy_packets=0 ... scheduled_bytes=0 (0.0000% of request) fence_emitted=1
DF2214   VERDICT: SILENT_TRUNCATION (fence says success, 0 of 4294967296 bytes scheduled)

DF2214 CASE variant=BASELINE pages=0x000fffff ...      # 2^20-1: just below the wrap
DF2214   num_loops=16385 copy_packets=16385 sum_chunk_dw=1073740800 ...
DF2214   scheduled_bytes=4294963200 (100.0000% of request) fence_emitted=1
DF2214   VERDICT: FULL_COPY

DF2214 CASE variant=BASELINE pages=0x000fffff ring=real64K ...   # real 64 KiB ring (rv770.c:1968)
DF2214   ERR_PTR(-12): ring reservation refused, ZERO packets, NO fence - loud failure

DF2214 CASE variant=BASELINE pages=0x00100000 ring=real64K ...
DF2214   ... scheduled_bytes=0 (0.0000%) fence_emitted=1 ... SILENT_TRUNCATION

With fix.diff (variant=FIXED): every case schedules exactly 100.0000% of the request (or fails loudly ERR_PTR(-12) when the ring genuinely cannot hold it), and every sub-2^20 case is bit-identical to baseline (16385 packets, same first/last chunk sizes, same fence behavior) — no regression.

Attacker input

num_gpu_pages comes from the TTM layer: radeon_move_blit (sys/dev/drm/radeon/radeon_ttm.c) computes num_pages = new_mem->num_pages * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE) and passes it straight to the asic copy callback. A buffer-object move of >= 4 GiB (num_gpu_pages >= 2^20) — plausible on large-GTT radeon systems — flips the bug. The DMA engine then copies a fraction (or nothing) while radeon_fence_emit still signals success, so ttm_bo_move_accel_cleanup publishes a destination buffer that was never written: silent video-memory integrity corruption.

DF-2214 — Verification Verdict

Status: reproduced (verbatim-code KLD rig on the QEMU guest) Impact: GPU-side memory integrity (silent truncation of large DMA copies); no host kernel memory corruption; no privilege-escalation primitive Confidence: certain

Verdict

REPRODUCED in kernel context by compiling the UNMODIFIED production function rv770_copy_dma (sys/dev/drm/radeon/rv770_dma.c lines 42-94, sha256 c1b2d82ab166f9e04f7158a8d6fe0506d22ee1c6f05aca121ca0ac9b5a6b547c, extracted from the guest tree file which is byte-identical to the audited tree, b33101a3...) into a KLD that drives it at the exact boundary state with fabricated-but-real-constant structures (radeon_ring with real ptr_mask semantics per radeon.h:2708-2717 and real ring geometry 64 KiB per rv770.c:1968, R600_RING_TYPE_DMA_INDEX=3 per radeon.h:149, RADEON_GPU_PAGE_SHIFT=12 per radeon.h:645, DMA_PACKET macro per rv770d.h:663-669, ring reservation semantics per radeon_ring.c:107-127).

Line 57 computes size_in_dw = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT) / 4 in 32-bit unsigned arithmetic (u32 size_in_dw, unsigned num_gpu_pages). For num_gpu_pages >= 2^20 the shift result exceeds 32 bits and wraps:

• 0x000FFFFF (2^20-1): size_in_dw=0x3FFFFC00, 16385 DMA_PACKET_COPY packets chunked at 0xFFFF, 4294963200 bytes scheduled = 100.0000% — correct, fence seq=1. FULL_COPY.
• 0x00100000 (2^20, a 4 GiB move): size_in_dw wraps to 0, num_loops=0, zero DMA packets, zero bytes scheduled — and the fence is still emitted and the function still returns a success fence (run_extract.log: "scheduled_bytes=0 (0.0000% of request) fence_emitted=1 ... VERDICT: SILENT_TRUNCATION").
• 0x00100001: wraps to 4096 bytes — exactly one packet with n=1024 dwords (first_pkt=0x30000400) out of a 4 GiB+4K request.
• 0x00100800: wraps to 8 MiB (0.1949% of request).
• 0xC0000000 (12 TiB request): wraps to 0 — silent total loss.

On the REAL ring geometry (64 KiB, rv770.c:1968) the contrast is sharpest: a 4 GiB-4K copy (correct arithmetic) needs 81933 dwords, radeon_ring_lock refuses with -ENOMEM and the production DRM_ERROR "radeon: moving bo (-12)" fires — a loud failure the caller can react to. The wrapped 4 GiB copy asks for only 8 dwords, locks trivially, emits nothing, and fences success: ttm_bo_move_accel_cleanup then publishes a destination buffer that was never written. Silent integrity corruption of GPU memory, undetectable by the caller. Deterministic: three identical runs (run_extract.log, run2_extract.log, run3_extract.log).

Negative claims checked (host memory / privesc)

• No host kernel memory corruption: the wrap can only SHRINK size_in_dw (wrapped = true_size mod 2^32 <= true_size), hence num_loops and the ring reservation num_loops*5+8 only ever shrink; ring writes are bounded by the reservation and by wptr &= ptr_mask inside the kmalloc'd ring buffer. Verified empirically: 4096-byte canary zones bracketing the ring buffer were INTACT after all 16 runs, count_dw never went negative (final=8, underruns=0). This is a GPU-data integrity bug, not a host memory-safety bug — there is no overwrite primitive and no route to uid=0 (the directive chain was assessed and closed: not a host memcorrupt/privesc class).
• Not remotely reachable without local GPU access: the trigger requires a

  = 4 GiB buffer-object move through the radeon TTM layer (radeon_ttm.c radeon_move_blit -> radeon_copy callback), i.e. an unprivileged local GPU client performing huge allocations/moves on rv770-class (r7xx/evergreen DMA) hardware with sufficient GTT. GPU-gated, Medium severity as filed.

Fix Status

fixed — A/B-validated in the same KLD. fix.diff (generated mechanically with diff -u, applies cleanly with patch -p1) widens the computation to 64 bit, matching the shape of the verified evergreen fix (findings/poc/batch_build/all_fixes.patch hunk at evergreen_dma.c):

• u64 size_in_dw; u32 cur_size_in_dw;
• size_in_dw = ((u64)num_gpu_pages << RADEON_GPU_PAGE_SHIFT) / 4;

FIXED variant results: every sub-2^20 case bit-identical to baseline (e.g. 0xFFFFF: same 16385 packets, 100.0000%, same fence seq) — zero regression; every >= 2^20 case schedules exactly 100.0000% of the request (0x100000: sum_chunk_dw=1073741824 = the full 4 GiB) on the oversized test ring, and on the real 64 KiB ring it now fails LOUDLY with ERR_PTR(-12) — exactly like a genuine 4 GiB-4K copy — instead of silently fencing an empty command stream. Residual nit (unchanged from evergreen fix): for absurd inputs (num_gpu_pages >= 2^22) cur_size_in_dw = size_in_dw narrows before the 0xFFFF cap on iterations after the first; harmless in practice because ring_lock refuses such reservations long before (observed: attempted_ndw= 251662093 -> lock_rc=-12), but a follow-up could cap before assigning.

Source File

sys/dev/drm/radeon/rv770_dma.c (function lines 42-94; defect at line 57, propagated through lines 58/69-81; success fence at line 83-93).

Iterations (poc_changes)

1. First kldload panicked the guest BEFORE the module executed: DFly's link_elf_obj loader cannot base .eh_frame relocations emitted without the kernel flag set ("panic: lost base for relatab", see kldload_panic_iteration.txt). Fixed by compiling with sys/platform/pc64/conf/kern.mk flags (-fno-asynchronous-unwind-tables -mcmodel=kernel -mno-red-zone -msoft-float ...). Guest reset with-src; not related to the finding (module had not run).
2. Kernel include environment replicated from sys/conf/kmod.mk semantics (merged machine/ namespace, machine_base/cpu_base/dragonfly symlinks, -D_KERNEL, -I/usr/src/include for -class forwarders; then dropped because systm.h fortified memset collides).
3. Trigger values exactly as the finding specifies (2^20-1, 2^20, 2^20+1, plus 2^20+2048, 0xC0000000, and real-ring 128 MiB control).

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.