DF-4144 — Dangling rdev->pm.dpm.ps after kfree-without-NULL at trinity_parse_power_table:1781 → double free in trinity_dpm_fini:2089, UAF via boot_ps at enable, ps_priv[0..i-1] leak

• File: sys/dev/drm/radeon/trinity_dpm.c
• Class: kernel heap double-free / use-after-free / leak (CWE-415/CWE-416)
• Verified via the verbatim-code rig (rig/): production slice byte-identical to the guest's /usr/src/sys (68 blocks, build.log); driven with a crafted Trinity DPM image and a deterministic fault-injecting allocator that fails the 2nd per-state kzalloc(sizeof(struct sumo_ps)), poisons freed allocations (PROT_NONE) and aborts on double free.
• Hardware gating: no AMD ASIC on the audit guest (env.txt) — kernel-context consequence of the demonstrated primitives is heap corruption / panic at driver unload (reboot or module unload) under the crafted-VBIOS / memory-pressure threat model.

What the rig demonstrates (baseline build = production code)

Fixed build (this finding's fix.diff, A/B on the identical image)

The parser error paths unwind (ps_priv[0..i-1] freed BEFORE dpm.ps is freed, then dpm.ps/boot_ps/uvd_ps NULLed), and trinity_dpm_fini is idempotent (ps=NULL, num_ps=0, priv=NULL after frees). Fixed run: inject → init -ENOMEM → fini clean, no double free, zero leaked allocations, and enable returns -EINVAL (the DF-4143 guard sees the NULLed boot_ps) — no UAF.

Build / Run (on the DragonFly guest)

cd rig && sh ./build.sh /usr/src DF-4144     # verbatim + fix-lines checks, cc
cd rig && sh ./run.sh                        # 14 modes x both builds

Verdict

Reproduced (verbatim-rig): the exact production code performs a kernel-equivalent double free at unload and a UAF read through the dangling boot_ps at enable; fix.diff (unwind + idempotent fini) removes both and the leak. See VERDICT.md, verdict.json.

DF-4144 — VERDICT

REPRODUCED via the verbatim-code rig on the DragonFly guest (same tree fidelity proof as DF-4143: 68 blocks identical to /usr/src/sys).

Root cause (confirmed)

trinity_parse_power_table (trinity_dpm.c:1734-1821):

• On per-state kzalloc(sizeof(struct sumo_ps)) failure (:1780) the parser executes kfree(rdev->pm.dpm.ps); return -ENOMEM; (:1781-1782) WITHOUT NULLing rdev->pm.dpm.ps, WITHOUT freeing the already-attached ps_priv[0..i-1], and with num_ps unset (:1806 runs only on success). If a BOOT-classified state was parsed before the failure, boot_ps (set at :1705) points into the freed array.
• trinity_dpm_init propagates the error, but radeon_pm_init_dpm discards it (radeon_dpm_init(rdev); radeon_pm.c:1448) and keeps the device alive.
• At unload radeon_pm_fini_dpm calls radeon_dpm_fini(rdev) UNCONDITIONALLY (radeon_pm.c:1705) → trinity_dpm_fini (:2080-2092): the num_ps loop frees nothing (num_ps==0), then kfree(rdev->pm.dpm.ps) at :2089 frees the already-freed pointer → double free; ps_priv[0] is leaked.

Rig observations (baseline, decisive lines)

• 4144-doublefree: RIG: init rc=-12; dpm.ps=0x80047e000 (kfreed at :1781, pointer NOT NULLed), num_ps=0, boot_ps=0x80047e000 (points INTO the freed array); RIG: allocator confirms dpm.ps ... is FREED while rdev still holds it; after the verbatim fini: RESULT: DOUBLEFREE ptr=0x80047e000 (allocation of 96 bytes freed a 2nd time) (96 = 2 × sizeof(struct radeon_ps)=48, both verbatim-verified). Allocator leak report shows the 128-byte ps_priv[0] allocation live at exit (leaked).
• 4144-uaf: with the swallow simulated (radeon_pm.c:1448-1453), the verbatim enable's trinity_update_current_ps(rdev, boot_ps) (:1129) reads boot_ps->ps_priv: RESULT: FAULT addr=0x80047e028 USE-AFTER-FREE in freed allocation 0x80047e000..0x80047e060 (+40 bytes in, alloc size 96) — +40 is exactly offsetof(struct radeon_ps, ps_priv), i.e. the literal rps->ps_priv read of trinity_get_ps over freed heap.

In kernel context: the double free corrupts the slab freelist (panic or worse on the next allocation of that bucket), and the UAF read feeds pi->current_ps = *new_ps — a 92-byte copy from freed memory. Both trigger under the crafted-VBIOS / memory-pressure (kzalloc failure) threat model; the injector models the kernel's genuine allocation-failure path.

Fix validation (A/B, identical image + identical injection)

fix.diff: (1) error unwinds at the three failure sites — free ps_priv[i-1..0] while dpm.ps is still valid, then NULL dpm.ps, boot_ps, uvd_ps after the production kfree; (2) idempotent fini (dpm.ps = NULL; num_ps = 0; priv = NULL; after the frees). Fixed run: RESULT: OK (fixed) unwind + idempotent fini, no double free, no leak (allocator report: zero live allocations), and the follow-on enable returns -EINVAL (DF-4143 guard + NULLed boot_ps) — no UAF. The checker proves the APPLY_DF4144_FIX lines are exactly the fix.diff additions (build.log, 27 lines). Kernel-rebuild validation not performed (path executes only on AMD ASICs, absent from the guest); validated in the rig per the established protocol. fix.diff authored against pristine sys/, never applied.

Honest limitations

• kzalloc-failure injection models memory pressure; on the target hardware the same code path is reachable with a large crafted ucNumEntries (255 × 128 B per state) at attach.
• The num_ps==0 leak-report is rig-allocator evidence; in-kernel the leak is 128 B per parsed state per failed probe (re-probe loops make it cumulative).

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.