# DF-3683 — Heap OOB write in phm_get_svi2_voltage_table_v0: VBIOS V0 dependency count (u8, up to 255) copied into fixed entries[32] before any trim

**File:** `sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c` (pass 2, GLM 5.3 re-audit)
**Severity:** High | **CVSS:** CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H | **CWE:** CWE-787 Out-of-bounds Write | **Confidence:** certain (source)

## What this is

Source-certain heap OOB write; runtime-inconclusive on this guest (no AMD GPU). phm_get_svi2_voltage_table_v0 (smu7_hwmgr.c:219-239, defined only in this file) copies voltage_dependency_table->count entries into voltage_table->entries[PP_ATOMCTRL_MAX_VOLTAGE_ENTRIES=32] (ppatomctrl.h:45,211). For V0 boards the count is the raw VBIOS ucNumEntries (u8, 1..255, no upper bound: processpptables.c:375-404), and the call sites (smu7_hwmgr.c:265-268 MVDD, :285-289 VDDCI, :313-317 VDDC) pass dyn_state.{mvdd,vddci,vddc}_dependency_on_mclk. The 'trimming' at :323-349 runs AFTER construction and only clamps the count field - it cannot undo the writes. With count=255 the loop writes 223 entries (1784 bytes) past entries[31], clobbering the adjacent vddci/mvdd/vddgfx voltage tables and the following members of the heap-allocated struct smu7_hwmgr (smu7_hwmgr.h:250-254). Precondition: crafted VBIOS (or VFIO/root sysfs pp_table) declaring SVID2 voltage control (atomctrl_is_voltage_controlled_by_gpio_v3) plus a dependency table with >32 entries. smu7 twin of DF-3585/DF-3619/DF-3644 (si/ci); the V1 twin of the same construction lives in smu_helper.c (DF-1797). Harness (verbatim function, real struct layouts) confirmed 223 forged OOB writes with VBIOS-controlled u16 voltage values corrupting canaries modelling the adjacent backend fields.

## Reproduce (harness on the audit QEMU guest)

```
scp -F dfbsd-qemu/config svi2_v0_overflow.c dfbsd-maxx:/tmp/DF-3683/
ssh -F dfbsd-qemu/config dfbsd-maxx 'cd /tmp/DF-3683 && cc -Wall -O0 -o t svi2_v0_overflow.c && ./t'
```

Expected: the run prints the confirmed-primitive line (`RESULT: ... CONFIRMED ...`).
See `run.log` (and `run.2.log` where present) for the decisive captured output,
`build.log` for the guest toolchain transcript, `env.txt` for the guest environment
(virtio-only, **no AMD GPU** — `pciconf -l` shows only 0x1237/0x1111 QEMU devices;
`drm.ko`/`amdgpu.ko` exist in /boot/kernel but are not loaded and have no hardware
to bind), which is why the in-kernel trigger itself is inconclusive on this guest.

## Fix

`fix.diff` (authored against the read-only sys/ tree; never applied there).