DF-1268 PoC — kv_dpm unbounded VBIOS counts: heap OOB WRITE (LATENT)

Status: source-confirmed real (certain); NOT reproducible on audit guest (no AMD GPU). Impact: heap OOB write past kv_power_info.*_level[] via crafted VBIOS count>8. Driver: sys/dev/drm/amd/amdgpu/kv_dpm.c (amdgpu kv path, not in GENERIC, no HW). The high_voltage_t guard is dead (never assigned).

Reproduce

./build.sh && ./run.sh   # stub; bug path is VBIOS-parse at GPU dpm init

See VERDICT.md + fix.diff.

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.