SET_RESOURCE SQ_TEX_VTX_VALID_BUFFER bound-check bypass: (size + offset) added in u32 (+ forced-size underflow) → GPU vertex fetch up to ~4 GB past the BO

DF-3839 — SET_RESOURCE (SQ_TEX_VTX_VALID_BUFFER) bound check bypass: (size + offset) added in u32 at evergreen_cs.c:2416 (+ forced-size underflow at :2419) -> GPU vertex fetch reads up to ~4 GB past the BO.

WHAT TO LOOK AT trigger.c SET_RESOURCE with word0=offset=0xfffffff0, word1=size=0x20: (size+offset) wraps to 0x10 -> "vbo resource seems too big" never fires -> GPU buffer base = gpu_offset + 0xfffffff0. fix.diff u64 promotion + underflow guard. verdict.json status inconclusive (no GPU on guest), source-level certain.

BUILD cc -O2 -o trigger trigger.c RUN ./trigger /dev/dri/card0 EXPECT On real pre-SI radeon HW the CS is accepted (no "vbo resource seems too big for the bo" in dmesg) although the buffer points far past the relocated BO. On the audit QEMU guest: ENOENT.

FAMILY DF-3766 (r100 INDX_BUFFER (value+1) wrap) — evergreen SET_RESOURCE instance.

DF-3839 VERDICT — status: inconclusive (hardware-gated), source-level: CERTAIN

Chain: 1. DRM-authenticated user, non-VM CS -> evergreen_packet3_check() PACKET3_SET_RESOURCE (evergreen_cs.c:2332). 2. Resource word7 type == SQ_TEX_VTX_VALID_BUFFER (2405). 3. :2414-2415 offset, size = raw u32 IB dwords. 4. :2416 if (p->rdev && (size + offset) > radeon_bo_size(robj)) — the addition happens in u32: offset=0xfffffff0, size=0x20 wraps to 0x10 which is <= any BO size -> check passes silently. 5. :2422-2425 offset64 = reloc->gpu_offset + offset (u64!) is programmed into the resource: the GPU vertex/index fetch now reads from bo_base + 0xfffffff0 — a 40-bit GPU address ~4 GB past the BO, i.e. unrelated GTT/VRAM allocations (other processes' buffers). Fetched data is returned as vertex attributes and can be rendered into an attacker-readable target -> cross-process GPU memory disclosure. 6. Secondary: when the wrapped check does fire with offset > bo_size, :2419 ib[...] = radeon_bo_size(robj) - offset underflows to a huge forced size, making the OOB window larger still.

Why not reproduced: guest has no DRI device (run.log: ENOENT; build.log: clean compile). The wrap (uint32)0xfffffff0 + 0x20 == 0x10 is arithmetic fact, not runtime-dependent.

Severity: Medium — matches DF-3766 (r100 sibling, Medium/certain): an OOB read primitive on the GPU from an unprivileged DRM client.

Fix: fix.diff — widen the comparison to u64 and reject offset >= bo_size before the forced-size write (which would underflow). Fix validation: not possible on this guest — fix_status not_applicable.

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.