# DF-3689 — Heap OOB read via unvalidated u8 vddInd/vddcInd from VBIOS indexing the voltage-lookup tables

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

## What this is

Source-certain heap OOB read; runtime-inconclusive on this guest (no AMD GPU). smu7_patch_voltage_dependency_tables_with_lookup_table uses each dependency record's vddInd/vddcInd - a raw u8 (0..255) from the VBIOS ATOM tables (process_pptables_v1_0.c:398 ucVddcInd etc.) - to index vddc/vddgfx_lookup_table->entries[] with no range check (:1860-1862, :1866-1868, :1873-1875, :1879-1881); smu7_patch_voltage_workaround does the same at :2135. The lookup tables are kmalloc'd for max_levels=16 records (process_pptables_v1_0.c:286-287/:295-296) while their count field is the VBIOS ucNumEntries, so indices above both 16 and count read adjacent kernel heap. The garbage value read is stored into the dependency record's vddc and later programs real voltages (hardware-safety impact) and feeds smu7_calc_voltage_dependency_tables; no direct userspace disclosure was found (sysfs pp_table dumps the raw atom table, not the patched records). DF-1168 covers the ucMemoryClockIndex/ucEngineClockIndex sinks; this is the distinct vddInd sink family. Harness: 239/255 crafted dep entries read past the 16-record allocation, max offset 2550 bytes past entries[0].

## Reproduce (harness on the audit QEMU guest)

```
scp -F dfbsd-qemu/config vddind_oob_read.c dfbsd-maxx:/tmp/DF-3689/
ssh -F dfbsd-qemu/config dfbsd-maxx 'cd /tmp/DF-3689 && cc -Wall -O0 -o t vddind_oob_read.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).