# DF-3683 — verdict narrative

## Finding

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.

## Root cause (kernel references)

- `sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:219`
- `sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:232`
- `sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:263`
- `sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:313`
- `sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:323`
- `sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.h:45`
- `sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.h:250`
- `sys/dev/drm/amd/powerplay/hwmgr/processpptables.c:391`

## What was verified, and how

1. **Source-level certainty.** Full-file pass-2 audit of smu7_hwmgr.c (5147 lines) with
   the parse-side preconditions traced into processpptables.c / process_pptables_v1_0.c
   (VBIOS u8 counts unvalidated; offset==0 subtables parse-legal NULL) and the struct
   geometry verified in ppatomctrl.h / smu7_hwmgr.h / hardwaremanager.h /
   dm_pp_interface.h.
2. **Harness on the guest** (DragonFly 6.5-DEVELOPMENT x86_64, `cc` base toolchain):
   `svi2_v0_overflow.c` reproduces the exact kernel code shape and/or arithmetic with 1:1 struct
   layouts. Output in `run.log`.
   Compiled with `-O0` — at `-O2` the compiler detects the array-index UB and
   misoptimizes the accounting loops (itself a hint of what the kernel code does).
3. **Hardware absence.** The guest is virtio-only: no AMD GPU on PCI, amdgpu not
   loaded. The in-kernel trigger requires an SMU7 ASIC (CI/Topaz/Tonga/Fiji/Polaris/
   Vegam) with a crafted VBIOS, VFIO passthrough of a malicious card, or a root
   sysfs pp_table write. Per pass-2 spawn instructions this is recorded as
   **inconclusive** (matching DF-3585/DF-3619/DF-3644 precedent for the same class),
   impact none *on this guest*.

## Fix validation

fix.diff authored post-verification against the read-only sys/ tree. Not built: a
kernel rebuild with drm cannot be exercised on a GPU-less guest, so fix validation is
`not_testable`; the diffs are minimal, local, and mechanically checkable against the
cited lines.

## 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.
