# DF-1268 — kv_dpm unbounded VBIOS dependency-table counts: heap OOB WRITE (LATENT)

## Verdict
**NOT REPRODUCED on the audit guest (LATENT / HW-gated).** The bug is
**confirmed real by source-level trace** (and marked `confidence=certain` in the
DB finding); it cannot fire here because there is no AMD APU/GPU, so the
`dev/drm/amd/amdgpu/kv_dpm.c` code path is dead at runtime.

## Mechanism (confirmed in source)
- Five loops iterate `for (i = 0; i < table->count; i++)` writing fixed-size
  destination arrays:
  - `kv_populate_uvd_table`  (`kv_dpm.c:915`)  → `pi->uvd_level[i]`      (`SMU7_MAX_LEVELS_UVD=8`, `kv_dpm.h:159`)
  - `kv_populate_vce_table`  (`kv_dpm.c:986`)  → `pi->vce_level[i]`      (`SMU7_MAX_LEVELS_VCE=8`, `:160`)
  - `kv_populate_samu_table` (`kv_dpm.c:1049`) → `pi->samu_level[i]`     (`SMU7_MAX_LEVELS_SAMU=8`,`:162`)
  - `kv_populate_acp_table`  (`kv_dpm.c:1115`) → `pi->acp_level[i]`      (`SMU7_MAX_LEVELS_ACP=8`, `:161`)
  - `kv_init_graphics_levels`(`kv_dpm.c:2426` and else-branch `:2446`) → `pi->graphics_level[i]` (`SMU__NUM_SCLK_DPM_STATE=8`, `:157`)
- `table->count` is the VBIOS atom `ucNumEntries` — a `u8`, 0..255, **uncapped**
  at all these sites.
- The apparent guard `if (pi->high_voltage_t && ...) break;` is **DEAD**:
  `pi` is `kzalloc`-zeroed (`kv_dpm.c` allocates `kv_power_info` with
  `kzalloc`) and `high_voltage_t` is **never assigned** anywhere in
  `kv_dpm.c` (`grep 'high_voltage_t ='` → no hits), so the condition is always
  false and the break never fires.
- A crafted VBIOS with `count > 8` therefore writes past the embedded arrays in
  `struct kv_power_info` → **heap OOB write** at dpm init. Sibling of
  DF-1136/DF-1141/DF-1166 (dpm_levels overflow).

## Why it does not reproduce here
`pciconf -lv` shows no AMD display device; `amdgpu.ko` is present in
`/boot/kernel/` but not loaded (nothing to probe). `kv_dpm` attaches only to
Kabini/Kaveri-class AMD APUs. Reaching the bug needs that hardware + a crafted
VBIOS. **Valid hard blocker**: path unreachable at runtime on this guest.

## Exploit chain
N/A for this guest — the write primitive is HW-gated (latent). On real AMD
hardware with a crafted VBIOS it is a kernel-heap OOB **write** (more severe
than DF-1254's read): controllable-ish content (VBIOS table entries) written
past `kv_power_info` into adjacent slab objects. No chain developed here
because the path is dead on the audit guest; characterization would require
the matching GPU.

## PoC changes
`trigger.c` is a documentation stub (bug path is VBIOS parse, not a syscall).

## Fix (`fix.diff`)
Cap each loop at its `SMU7_MAX_LEVELS_*` constant so a VBIOS `count > 8`
cannot overflow:
```
for (i = 0; i < table->count && i < SMU7_MAX_LEVELS_<X>; i++)
```
applied to all six loops (uvd/vce/samu/acp + the two graphics-level branches).
Applies cleanly (`patch -p1` rc=0). Matches the finding proposal ("cap i<SMU7_MAX_LEVELS_*").

## Fix validation
`not_testable` — code path unreachable on audit guest; diff validated to apply
cleanly and is syntactically reviewed. Building the amdgpu stack is not
warranted for a non-reproducible latent OOB write.