# DF-4006 — fiji VCE/ACP/UVD level population NULL-derefs when the PowerPlay table omits usMMDependencyTableOffset

**File:** `sys/dev/drm/amd/powerplay/smumgr/fiji_smumgr.c:1433` (VCE), `:1472` (ACP), `:1569` (UVD), `:2374/:2407` (update paths)
**Class:** NULL pointer dereference → kernel panic (DoS) — DF-1419/1575 family
**Severity:** Low · **Confidence:** certain (source) · runtime hardware-gated

## Build / Run / Expected
Same demonstrator as DF-4001 (`./build.sh && ./run.sh`, section `=== DF-4006 ===`):
```
child took signal 11 on mm_table->count — in-kernel equivalent: page fault on NULL+offset during fiji_init_smc_table (driver attach / resume) => panic
```

## Source chain
`process_pptables_v1_0.c:796` leaves `pp_table_information->mm_dep_table = NULL`
when the VBIOS PowerPlay table has `usMMDependencyTableOffset == 0` — the parser
keeps `result == 0` and continues (`:800-801` gates only the Powertune table on
result). Nothing between the parser and `fiji_init_smc_table` consumes or checks
mm_dep_table (smu7 only uses sclk/mclk/pcie). Then
`fiji_populate_smc_vce_level:1433` does `table->VceLevelCount = (uint8_t)(mm_table->count);`
on NULL → page fault during pp_hwmgr init (device attach / resume) — a crafted-vBIOS
boot-time/attach panic, same context class as DF-1419/DF-1550/DF-1610.

## Fix
`fix.diff` (shared): NULL-check + clamp in all three populate functions (and the
update paths keep the existing count>0 shape). Compile-validated via nativekernel
rebuild (fix_build.log).