DF-1342 — r600_dma_cs_parse reads/writes the IB past length_dw (DMA-packet heap OOB at IB end)

File: sys/dev/drm/radeon/r600_cs.c:2388-2518 Class: OOB read (info leak) + OOB write (corruption) of the IB allocation

Status: INCONCLUSIVE at runtime — confirmed real source bug, hardware-gated on this guest

The vulnerable code path was traced line-by-line in sys/ and confirmed to be a genuine bug (missing bounds check / integer overflow / UAF race). However it is not exercisable on the DragonFly audit guest because the guest has neither an AMD GPU nor any audio controller:

• PCI shows only vgapci0 class=0x030000 (QEMU stdvga, chip 0x11111234) — no AMD GPU.
• No PCI audio device (class 0x0401/0x0403); hw.snd empty; no /dev/dsp.
• radeon.ko is a loadable module only (NOT in X86_64_GENERIC), is not loaded, and cannot be kldload'd by an unprivileged user — and even if loaded would not attach without the hardware.

This is the valid hard-blocker case "vulnerable code path unreachable at runtime on this guest AND no harness can exercise it (device-integrated parser / ioctl / hardware-dependent race)." The bug is a real latent defect that would manifest on a system with the relevant hardware + the module loaded.

Mechanism (confirmed by 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.

Live trigger conditions

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.

Fix

A standalone, git apply-able fix is in fix.diff. Compile-validated: applied to in-guest /usr/src and the radeon module rebuilt under -Werror (rc=0, no warnings/errors in the patched translation unit). See build_fix.log.

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').

Reproduce / validate

# 1. Confirm the bug site exists (read-only source trace):
grep -n ... sys/dev/drm/radeon/r600_cs.c

# 2. Validate the fix compiles (on the audit guest):
scp -F dfbsd-qemu/config findings/poc/DF-1342/fix.diff dfbsd:/root/fix.diff
./dfbsd-qemu/vm.sh run_root 'cd /usr/src && patch -p1 --forward < /root/fix.diff'
./dfbsd-qemu/vm.sh run_root 'cd /usr/src/sys/dev/drm/radeon && KERNCONF=X86_64_GENERIC SYSDIR=/usr/src/sys make -m /usr/src/share/mk'

# 3. (requires real hardware) Exercise the bug: attach an AMD GPU / audio device and trigger.

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.