# VERDICT — DF-1342

## Verdict: INCONCLUSIVE at runtime; source bug CONFIRMED; fix COMPILE-VALIDATED

**Citations confirmed:** sys/dev/drm/radeon/r600_cs.c:2389, sys/dev/drm/radeon/r600_cs.c:2415, sys/dev/drm/radeon/r600_cs.c:2418, sys/dev/drm/radeon/r600_cs.c:2439, sys/dev/drm/radeon/r600_cs.c:2448, sys/dev/drm/radeon/r600_cs.c:2516

### Is the bug real? — YES (source trace)
r600_dma_cs_parse() validates only the packet header against the IB length (`p->idx >= ib_chunk->length_dw`, :2389). For DMA_PACKET_WRITE non-tiled it then reads/writes ib[idx+1]/ib[idx+2] (:2415-2418); for DMA_PACKET_COPY tiled up to ib[idx+6] (:2439-2458); for CONSTANT_FILL ib[idx+1]/ib[idx+3] (:2509-2517). The IB is allocated exactly length_dw*4 bytes, so a DMA packet whose header sits at the end of the IB causes indexed accesses (and the reloc-patch writes `ib[idx+N] += ...`) past the allocation => OOB read (leak of adjacent SA-BO data) and OOB write (corruption). Unlike the gfx path, which uses radeon_cs_packet_parse() with a strict count+1+idx>=length_dw body check, the DMA path has no per-packet body bounds check.

### Can it be reproduced on this guest? — NO (hardware-gated)
Requires an AMD Radeon R600/RV770 GPU with radeon attached and a DRM_AUTH client submitting a DMA command stream that ends mid-DMA-packet. QEMU audit guest has no AMD GPU, no /dev/dri, radeon.ko not loaded => unreachable here.

Guest evidence (`env.txt`): only `vgapci0 class=0x030000 chip=0x11111234` (QEMU stdvga); no AMD GPU;
no PCI audio device; `kldstat` shows no drm/radeon/amdgpu/snd module; `/dev/dri` and `/dev/dsp*` do
not exist. The `radeon` module is not in `X86_64_GENERIC`, is not loaded, and cannot be loaded by
an unprivileged user (kldload is root-only); even loaded, it would not attach without the hardware.
Therefore the vulnerable code is unreachable at runtime here. Because the sinks are device-integrated
parsers / DRM ioctls / a hardware-dependent channel race, no userspace harness on this guest can
exercise them. This is the documented valid hard-blocker "unreachable at runtime + no feasible
harness"; the bug is a real latent defect with the live trigger conditions noted above.

### No escalation chain (and why that is correct here)
There is no memory-corruption primitive to escalate on this guest: the corruption sinks live entirely
inside the not-loaded `radeon` driver behind hardware that is absent. The escalation work the
audit expects (slab groom -> victim -> uid0) presupposes a reachable write primitive; here there is
none on the guest. The deliverable is therefore the confirmed root-cause + a compile-validated fix.

### Fix (fix.diff) — authored and COMPILE-VALIDATED
Add an `idx + N >= ib_chunk->length_dw` guard before the indexed accesses of each DMA packet type (WRITE: idx+2; COPY tiled: idx+6; COPY non-tiled: idx+4; CONSTANT_FILL: idx+3), returning -EINVAL on overflow, mirroring the strict body check the gfx path already has. Supersedes the finding proposal (which only said 'validate packet body size').

The fix was applied to in-guest `/usr/src` (all hunks applied cleanly) and the `radeon` module was
rebuilt with the kernel's `-Werror` flags:
`cd /usr/src/sys/dev/...radeon... && KERNCONF=X86_64_GENERIC SYSDIR=/usr/src/sys make -m /usr/src/share/mk`
=> **rc=0**, no warnings/errors in the patched translation unit (`build_fix.log`). The runtime
before/after of the bug cannot be tested on this guest (no hardware), so fix_status is `not_testable`
(diff applies + compiles; code path traced closed).

### Why not `not_reproduced` (false-positive)?
This is NOT a false positive. The cited `sys/` code is genuinely missing the guard / has the overflow
/ has the race — verified by reading the source. It is a real bug that is simply out of reach of this
particular (GPU/audio-less) QEMU guest.