# DF-1402 — trinity_parse_power_table VCE clk_idx OOB read (PoC)

## Summary
The VCE power-state loop in `trinity_parse_power_table`
(`sys/dev/drm/radeon/trinity_dpm.c:1816-1823`) indexes the clock info array with
a VBIOS-supplied 6-bit `clk_idx` (0..63) and **no bounds check**. With
`ucNumEntries=1` and `clk_idx=63` that is a ~1008-byte OOB read. **Read-only
primitive** → no escalation; ceiling = wrong VCE engine clock / OOB info read
(DoS).

## Reachability
`radeon` is a loadable module (`radeon.ko`), not in GENERIC, attaching only to
AMD/ATI Radeon GPUs. The QEMU guest has no AMD GPU, so the bug is **not
live-reachable here**. Proven deterministically with a byte-exact harness
replicating `struct _ClockInfoArray` (`pptable.h:446-454`), where `clockInfo`
is a **byte array** so `[idx*ucEntrySize]` is a byte offset.

## Build / run
```sh
./build.sh && ./run.sh
```

## Expected output (bug present)
```
  level 0: clk_idx=63 -> byte offset [63*16=1008] OOB -> sclk=0xdddddd
guard present? : NO (clock path at :1789 checks, this VCE loop does not)
OOB READ CONFIRMED: clk_idx=63 vs ucNumEntries=1 reads ~1008 bytes OOB per level (idx*ucEntrySize).
```
On a fixed driver the guard `continue`s on `clk_idx >= ucNumEntries`.

## Fix
Add the missing guard mirroring the clock path: if
`clock_array_index >= clock_info_array->ucNumEntries`, `continue`
(`fix.diff`). Validated to compile into a rebuilt `radeon.ko` (`-Werror`,
rc=0; `trinity_dpm.o` built).

## Files
- `trinity_vce_oob.c` — byte-exact harness.
- `build.sh` / `run.sh` / `run.log` / `env.txt` / `fix.diff` / `VERDICT.md` / `manifest.json`.