# VERDICT — DF-1340

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

**Citations confirmed:** sys/dev/drm/radeon/r600_cs.c:353, sys/dev/drm/radeon/r600_cs.c:430, sys/dev/drm/radeon/r600_cs.c:440, sys/dev/drm/radeon/r600_cs.c:443, sys/dev/drm/radeon/r600_cs.c:520, sys/dev/drm/radeon/r600_cs.c:622, sys/dev/drm/radeon/r600_cs.c:623

### Is the bug real? — YES (source trace)
In r600_cs_track_validate_cb(), `tmp` is declared u32 (:353) and computed as nblocksy*nblocksx*blocksize*nsamples (:430). With maximal attacker-chosen surface geometry (8192*8192*8*16 = 2^33) the u32 product wraps to a tiny value, so the check `(tmp + cb_color_bo_offset[i]) > radeon_bo_size(...)` (:443) passes for an undersized BO; the GPU then writes colour-buffer data past the BO into adjacent GTT/VRAM (another process's BO). The tiled branch (:440) multiplies tmp by the slice count, compounding the overflow. r600_cs_track_validate_db() has the identical flaw at :622 (ntiles*bpe*64*nviews*nsamples, also u32 via :520). Both reached from the DRM_AUTH command-submission path.

### Can it be reproduced on this guest? — NO (hardware-gated)
Requires an AMD Radeon R600-family GPU with the radeon driver attached and a DRM_AUTH client issuing a crafted CS. The QEMU audit guest has only a QEMU stdvga (0x11111234) — no AMD GPU, no /dev/dri, radeon.ko not loaded — so r600_cs_track_validate_cb/db are 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
Compute the CB size in a new u64 `tmp64` (cast the first operand to u64) and use tmp64 in the bounds comparison and dev_warn; split the DB `tmp` decl to u64 and cast the first operand. This removes the u32 overflow so the bounds check is sound. Supersedes the finding proposal (which only said 'compute in u64').

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.