# DF-4665 — VERDICT

**Status: reproduced** (harness; no AMD GPU on the audit guest — methodology
identical to DF-3683/DF-3686: verbatim kernel function + 1:1 struct layouts,
canary-guarded adjacency, run on the DragonFly 6.5-DEVELOPMENT guest).

## What was run

`smu7_odn_overflow.c` compiles the **verbatim** body of
`smu_get_voltage_dependency_table_ppt_v1` (smu_helper.c:675-699) against 1:1
copies of the kernel struct layouts
(`phm_ppt_v1_clock_voltage_dependency_record` — 28 bytes, compiler-confirmed;
`phm_odn_clock_levels`, `smu7_odn_clock_voltage_dependency_table` with
`entries[8]`, `smu7_odn_dpm_table`, and a `struct smu7_hwmgr`-prefix buffer
with a 64-word canary region standing in for the members after
`odn_dpm_table`).

## Observations (run.log, guest cc 8.3, DF 6.5-DEVELOPMENT)

1. **count=16, 2 distinct clocks** — the DF-1166 dedup loop appends only 2
   `dpm_levels` (IN BOUNDS, the known finding does NOT fire), then the odn
   copy writes 16 × 28 = 448 bytes into `entries[8]`: **224 bytes OOB**,
   `vdd_dependency_on_mclk.count` corrupted from 0 to 102500 (a VBIOS clk
   value). Proves this bug fires on inputs the filed siblings do not cover.
2. **count=255, 2 distinct clocks** — DF-1166 site still in bounds; odn copy
   writes **6916 bytes past entries[7]**, of which **6420 bytes past the end
   of the backend-shaped object**; **55/64 canary words smashed**;
   `odn_mclk_min_limit`, `min_vddc`, `max_vddc` all overwritten with
   attacker-record contents. On the real kernel this is a linear heap overflow
   of the `kzalloc`'d `struct smu7_hwmgr` with fully VBIOS-controlled data,
   running into whatever slab object follows.
3. **Control count=8** — no corruption (function behaves correctly when the
   source happens to be in range).
4. **Patched twin** (fix.diff applied to the harness function, call site
   passes `MAX_REGULAR_DPM_NUMBER`): stored count clamped to 8, zero canary
   damage for count=16 and count=255 — **fix validated**.

## Exploit chain (realistic ceiling)

Crafted VBIOS / VFIO pp_table write on an smu7 board (Tonga/Fiji/Polaris10/
VegaM) with OverDrive enabled → at driver load
`smu7_setup_default_dpm_tables` → `smu7_odn_initial_default_setting` → this
copy → controlled 28-byte-stride heap overflow inside/past `struct smu7_hwmgr`
→ kernel heap corruption (adjacent slab objects; `struct smu7_hwmgr` is a
several-KB kmalloc). Grooming the slab neighbour of the hwmgr backend could
turn this into code execution; at minimum a deterministic kernel panic. The
audit guest has no AMD GPU, so the chain is demonstrated at the
primitive level (above), matching the methodology precedent of DF-3683.

## Kernel references

* sys/dev/drm/amd/powerplay/hwmgr/smu_helper.c:675-699 (the unbounded copy)
* sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:844-845,856-857 (smu7 call sites, entries[8] dest)
* sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:962-968, 4844-4846 (reachability)
* sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.h:95,177-190 (MAX_REGULAR_DPM_NUMBER=8, odn tables)
* sys/dev/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c:436,468 (count = raw ucNumEntries)
* sys/dev/drm/amd/powerplay/hwmgr/vega10_hwmgr.c:318-323 (vega10 leg — DF-3703, not re-filed)

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.