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)

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.

DF-4143 — VERDICT

REPRODUCED via the verbatim-code rig on the DragonFly guest (DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 ... x86_64), with all 68 VERBATIM blocks of the rig proven byte-identical to /usr/src/sys/dev/drm/radeon/{trinity_dpm.c,trinity_dpm.h,sumo_dpm.c,sumo_dpm.h,r600_dpm.c,atom.c,atom-bits.h,radeon.h,pptable.h,atombios.h,atom-types.h,trinityd.h} — the tree the running kernel was built from (build.log: 68× "identical to production"; guest and host tree md5s match).

Root cause (confirmed line-by-line)

• rdev->pm.dpm.boot_ps is assigned ONLY inside trinity_parse_pplib_non_clock_info under rps->class & ATOM_PPLIB_CLASSIFICATION_BOOT (trinity_dpm.c:1704-1706). A crafted VBIOS whose non-clock infos carry no BOOT classification parses successfully (init rc=0, num_ps=2, boot_ps=0x0 — run.log mode 4143-enable) leaving boot_ps == NULL.
• radeon_pm_init_dpm then runs radeon_dpm_init(rdev); with the return value DISCARDED (radeon_pm.c:1448), sets current_ps = requested_ps = boot_ps (NULL, :1449) and calls radeon_dpm_enable(rdev) (:1453).
• The verbatim trinity_dpm_enable walks its MMIO prep on the rig's fake register file and ends with trinity_update_current_ps(rdev, rdev->pm.dpm.boot_ps) (trinity_dpm.c:1129) → trinity_get_ps(rps) (:1075 → :355) reads rps->ps_priv at NULL + 40.

Rig observations (baseline build, decisive lines)

• 4143-enable: RESULT: FAULT addr=0x28 ... NULL-pointer dereference at member offset 40 — 40 == offsetof(struct radeon_ps, ps_priv), printed from the verbatim struct in layout mode (sizeof(struct radeon_ps)=48, ps_priv@40, last member). In kernel context: page fault → panic at GPU attach; same code path on every suspend (radeon_pm.c:1257-1260).
• 4143-presel: RESULT: FAULT addr=0x0 — trinity_dpm_pre_set_power_state dereferences rdev->pm.dpm.requested_ps (:1240), which radeon_pm.c:1449 left NULL. In kernel: panic on the first power-state transition.
• 4143-initfail: parse aborts -EINVAL at :1777-1778 (the DF-4146 NULL-word abort); the rig prints the radeon_pm.c:1448-1453 swallow sequence and the verbatim enable faults at 0x28 — the exact swallowed-error panic chain.
• good: a well-formed crafted image drives init/enable/disable/pre_set/ get_sclk/fini to completion — the fault is specific to the missing BOOT state, not to the rig environment.

Fix validation (A/B, identical crafted images)

fix.diff adds NULL guards to trinity_dpm_enable, trinity_dpm_disable and trinity_dpm_pre_set_power_state (the three in-file dispatch entries). Fixed build: all three 4143 modes return -EINVAL with no fault (RESULT: OK (fixed) ... rejected cleanly), good unchanged. The checker additionally proves the APPLY_DF4143_FIX-guarded lines are exactly the fix.diff additions (build.log). Kernel-rebuild validation was not performed: the fix site executes in-kernel only on Trinity/Richland ASICs, absent from this guest (env.txt); per the established verbatim-rig protocol (sibling findings DF-4165/4247/4388/4396) the fixed slice was validated in the same rig. fix.diff is authored against the pristine read-only sys/ tree and was never applied there (verified git apply --check clean).

Honest limitations

• No AMD GPU on the audit guest ⇒ no in-kernel execution; the panic itself is the kernel-context consequence of the demonstrated NULL dereference (identity of code proven against the running kernel's source tree).
• The long-term fix is honoring trinity_dpm_init's return in radeon_pm.c:1448 (different file, out of scope for this finding's fix.diff); the in-file guards are the minimal safety net for 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.