# DF-4143 — NULL `boot_ps` page-fault in `trinity_dpm_enable` (:1129) / `trinity_dpm_disable` (:1177) / `trinity_dpm_pre_set_power_state` (:1240) when the VBIOS power table has no BOOT-classified state or `trinity_dpm_init` failed and `radeon_pm.c:1448` swallowed the error

- File: `sys/dev/drm/radeon/trinity_dpm.c` (Trinity/Richland APU DPM)
- Class: kernel NULL-pointer dereference → page fault → panic (CWE-476)
- **Verified via the verbatim-code rig** (`rig/`, proven sibling evidence class
  DF-4165/DF-4247/DF-4388/DF-4396): the production parser, enable/disable/
  pre_set paths and every layout-relevant struct were machine-extracted
  byte-identical from `sys/` (`gen_rig.sh`), and `check_verbatim.sh` re-proved
  block identity **on the DragonFly guest against `/usr/src/sys` — the tree
  its running kernel was built from** (68 blocks identical; see `build.log`).
- Hardware gating: the guest has only the Bochs SVGA (0x1234:1111), no AMD
  ASIC (`env.txt`), so the path never executes in this guest's kernel. In
  kernel context the demonstrated faults are page faults → panic at GPU
  attach / first suspend — the finding's threat model (crafted/corrupted
  VBIOS on a Trinity/Richland APU, or a root-written pp_table after
  `sysctl hw...` style DPM reinit).

## What the rig demonstrates (baseline build = production code)

| mode | result |
|---|---|
| `good` | well-formed image: init/enable/disable/pre_set/get_sclk/fini all clean (regression control) |
| `4143-enable` | table with no BOOT-classified state → `boot_ps` stays NULL → verbatim `trinity_dpm_enable` faults reading `NULL->ps_priv` at **address 0x28 = 40 = offsetof(struct radeon_ps, ps_priv)** (trinity_dpm.c:1129 → trinity_update_current_ps:1075 → trinity_get_ps:355) |
| `4143-presel` | `requested_ps` NULL (the value radeon_pm.c:1449 leaves after a NULL `boot_ps`) → verbatim `trinity_dpm_pre_set_power_state` faults at **address 0x0** (`*rdev->pm.dpm.requested_ps`, :1240) |
| `4143-initfail` | parse aborts with -EINVAL (NULL `power_state[1].clock_info`, :1777-1778) → the rig simulates `radeon_pm.c:1448` DISCARDING the init error and :1453 calling enable → fault at **0x28** again |

## Fixed build (this finding's `fix.diff` + the sibling fixes, A/B on identical images)

All three modes return `-EINVAL` from the guards (`no boot state; dpm init did
not succeed`) — no fault, clean rejection; `good` still passes.

## Build (on the DragonFly guest)

```
cd rig && sh ./build.sh /usr/src DF-4143
```

verifies all VERBATIM blocks against `/usr/src/sys`, verifies the
`APPLY_DF4143_FIX`-guarded lines equal this pack's `fix.diff` additions, then
compiles `rig_base` (production code) and `rig_fixed`.

## Run

```
cd rig && sh ./run.sh
```

14 modes × both builds; exit codes 0 = clean, 88 = fault demonstrated,
89 = double free demonstrated.

## Verdict

Reproduced (verbatim-rig): the exact production code, byte-identical to the
running kernel's source, NULL-dereferences `boot_ps->ps_priv` at offset 40 in
`trinity_dpm_enable`, `boot_ps`-derived NULL `requested_ps` in
`trinity_dpm_pre_set_power_state`, and after the swallowed init error — page
fault / panic in kernel context. `fix.diff` (NULL guards at all three
dispatch entries) eliminates every mode. See `VERDICT.md`, `verdict.json`.