# DF-3686 — Zero-count DPM tables (ignored setup failures) drive unsigned index 0xFFFFFFFF into dpm_levels[] - wild read/write ~48GB out and OOB reads/div0 across OD paths

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

## What this is

Source-certain index-underflow family; runtime-inconclusive on this guest (no AMD GPU). Root cause 1: smu7_setup_default_dpm_tables (:950-953) ignores the -EINVAL returns of smu7_setup_dpm_tables_v0/v1, and smu7_hwmgr_backend_init (:2563-2566) likewise ignores smu7_set_private_data_based_on_pptable_v0's; a VBIOS whose V0 dependency offsets are 0 (parse-legal, processpptables.c:1304-1310) leaves sclk/mclk_table.count == 0. Root cause 2: use sites index dpm_levels[count-1] / dpm_levels[i-1] with unsigned arithmetic. Sinks: smu7_find_dpm_states_clocks_in_dpm_table (:3594/:3614-3616) - loop exits with i=0 so dpm_levels[(uint32_t)0-1] = dpm_levels[0xFFFFFFFF] = +51,539,607,540 bytes (~48 GB) - a WILD kernel READ and, when the garbage compares below the requested SCLK, a WILD WRITE of that clock value, on every power-state change; smu7_get_profiling_clk :2740 (sclk dpm_levels[count-1] read, mclk value 0 div0 is DF-1170); smu7_get_maximum_link_speed :3642-3645 (pcie dpm_levels[count-1]); smu7_get_sclk_od :4534-4539 and smu7_get_mclk_od :4576-4581 (index -1 reads plus DIV_ROUND_UP divide-by-zero when the golden value is 0); smu7_get_max_high_clocks :4745-4750; OD_RANGE print :4487/:4490; and a NULL deref of dyn_state.vddc_dependency_on_sclk at :4630/:2755 on the V0 branch. Harness reproduces the exact unsigned index arithmetic and, in crash mode, executes the verbatim kernel access: SIGSEGV (kernel equivalent: page fault in kernel mode -> panic).

## Reproduce (harness on the audit QEMU guest)

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