# DF-2146: Unbounded AUX reply byte count causes OOB write on DP read path

## Verdict: NOT REPRODUCED (HW-gated) — source-confirmed real bug

## Reachability
**NOT reachable on this QEMU guest.** `radeon_dp_auxch_ub926()` is in
`sys/dev/drm/radeon/radeon_dp_auxch.c`, part of `radeon.ko`. Requires an AMD Radeon GPU
with DisplayPort. No AMD GPU present on this QEMU guest.

## Mechanism (source-confirmed)
`radeon_dp_auxch_ub926()` at `radeon_dp_auxch.c:177-191`:
1. Line 65: `u8 *buf = msg->buffer` — caller-supplied buffer
2. Line 71: `WARN_ON(msg->size > 16)` — buffer max 16 bytes (commonly 1 for register reads)
3. Line 177: `bytes = AUX_SW_REPLY_GET_BYTE_COUNT(tmp)` — 5-bit MMIO field, range 0..31,
   **sourced from the DP sink on the wire** (attacker-controlled if malicious DP device)
4. Line 185-188: `for (i = 0; i < bytes - 1; i++) { ... buf[i] = (tmp >> 8) & 0xff; }`

If `bytes > msg->size + 1` (e.g. `bytes=31`, `msg->size=1`), the loop writes up to 30 bytes
into a buffer sized for 1 → **heap/stack OOB write**.

`AUX_SW_REPLY_GET_BYTE_COUNT(x)` is `((x >> 24) & 0x1f)` (radeon_dp_auxch.c:40) — a hardware
register field that a malicious DisplayPort sink device can set to any value 0..31.

## Primitive
- Class: heap/stack OOB write (attacker controls write count via malicious DP device)
- Write size: up to 30 bytes past buffer end
- Write content: MMIO register reads (partially attacker-influenced via DP AUX protocol)

## Fix
`fix.diff`: Clamp `bytes` to `msg->size + 1` before the copy loop:
```c
if (bytes > msg->size + 1)
    bytes = msg->size + 1;
```