# VERDICT — DF-4001

**Status: inconclusive at runtime (hardware-gated); source-certain.**

## Reproduced

The *index arithmetic and corruption extents* are reproduced on the audit guest
by `trigger_analysis.c` (run.log), using the kernel's own packed headers:

| walk | sink (kernel object) | bound | demo counts | OOB observed |
|---|---|---|---|---|
| `fiji_populate_all_graphic_levels:1026` | `GraphicsLevel[8]` (heap, `fiji_smumgr` kzalloc @ `fiji_smumgr.c:339`) | 8 | sclk=12 | 4 level writes / 176 B past; `[count-1]` store at `:1042` also OOB |
| `fiji_populate_all_memory_levels:1238` | `MemoryLevel[4]` (heap) | **4** | mclk=6 | 2 writes / 48 B past (mclk count 5 suffices) |
| `fiji_program_memory_timing_parameters:1537-1546` | `SMU73_Discrete_MCArbDramTimingTable` **STACK** object (`:1533`) | entries[8][4] | 12×6 | 26 entry writes past, max linear entry 49 of 32, 216 B into caller frame; 255/255 → 15,300 B past |

Struct geometry measured with the kernel's own headers:
`sizeof(DpmTable)=1632`, `GraphicsLevel@+236` (44 B/level), `MemoryLevel@+612`
(24 B/level), arb entry 12 B, arb table 384 B.

The in-kernel fault could not be observed: the audit guest has no AMD GPU
(env.txt: amd-gpu=0, virtio-only), and the trigger requires a Fiji (Fiji XT /
R9 Fury) card with a crafted vBIOS — physical attacker / malicious vBIOS /
hostile eGPU, same gate as DF-4000 (iceland), DF-3908/3939/3940.

## Why the counts are attacker-controlled and unclamped (three-hop provenance)

1. `process_pptables_v1_0.c:425-436` `get_sclk_voltage_dependency_table` and
   `:378-391` `get_mclk_voltage_dependency_table` set `table->count = ucNumEntries`
   (VBIOS byte, ≤ 255); the allocation matches the count, so no clamp exists anywhere.
2. `hwmgr.c:86` sets `pp_table_version = PP_TABLE_V1` by default; `hwmgr.c:127-130`
   pins CHIP_FIJI to `fiji_smu_funcs` (only CI/TOPAZ downgrade to PP_TABLE_V0).
3. `smu7_hwmgr.c:783-810` (`smu7_setup_dpm_tables_v1`) copies the dep-table
   entries (dedup by clk) into `dpm_table.sclk_table/mclk_table.count` —
   unclamped vs `MAX_REGULAR_DPM_NUMBER`(8); the en-route `dpm_levels[8]`
   smash is DF-1166 (pass 1, smu7_hwmgr.c). The fiji-side sinks below are
   this file's: `GraphicsLevel[8]`, `MemoryLevel[4]`, stack `entries[8][4]`,
   plus the `:1792-1795` DDT `GraphicsLevel[j]` OOB read.

No intervening clamp exists: grep the whole populate path — the only min()
on pcie is `smu7_hwmgr.c:561` (which is why LinkLevel is safe; see negative
notes in the audit result).

## Exploitability (why High)

- Heap: count 12 already writes 176 B past GraphicsLevel[8] *inside* the
  `struct fiji_smumgr` allocation, corrupting MemoryACPILevel/MemoryLevel/
  LinkLevel/Uvd/Vce/Acp/Samu/Ulv/Smio...; count ≥ ~45 runs past the whole
  kzalloc into adjacent heap (count 255 → 10.8 KB). Content is
  VBIOS-influenced (clocks/voltages per level).
- Stack: the arb walk is a linear stack smash up to 15.3 KB past a 384-byte
  frame object in the return-address direction; DragonFly kernels are built
  without stack protectors by default. Trigger context = driver attach/resume
  (privileged), so this is malicious-vBIOS-class, not unprivileged-local.

## Fix validation

`fix.diff` clamps all walks/counts to the SMU73 bounds. Applied to pristine
guest /usr/src (md5 800babd0.. → d50bdc81..), full `make nativekernel
KERNCONF=X86_64_GENERIC` rebuild completed (fix_build.log / fix_kernel_full.log),
then reverted. Runtime re-test impossible on this guest (no AMD GPU).

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