DF-3754 — NULL-pointer dereference of rdev->pm.dpm.boot_ps / ps_priv in ni DPM (crafted VBIOS)

File: sys/dev/drm/radeon/ni_dpm.c (pass 2) Family: radeon twin of si DF-3610 / ci DF-3646 (amdgpu DF-3586 / DF-3623)

Build

cc -O2 -Wall -o harness harness.c

(No AMD NI GPU on the QEMU audit guest — virtio-only — so verification is a userspace logic harness that executes the exact kernel call graph with verbatim structs and offsets; see env.txt for the hardware/module check.)

Run

./harness

Expected output

[A] ... child died from signal 11: read at NULL+0x28
    >>> kernel: page-fault at 0x28 -> panic during DPM enable <<<
[A2] ... child died from signal 11: read at NULL+0x0
    >>> kernel: page-fault at 0 -> panic on first state change <<<
[B] Fixed path ... rc=-EINVAL (DPM enable refused, no dereference)

[A] proves the boot_ps==NULL dereference chain (ni_dpm_enable -> ni_init_smc_table -> ni_populate_smc_initial_state(NULL) -> ni_get_ps(NULL)->ps_priv, fault address 0x28 = offsetof(struct radeon_ps, ps_priv) on LP64). [A2] proves the ps_priv==NULL variant (ni_update_requested_ps: *new_ps with new_ps==NULL, fault address 0x0). [B] shows the fix.diff guard rejecting the configuration instead.

Fix

fix.diff — refuse to enable DPM without a boot state (mirrors the si DF-3610 fix). Validated: applies cleanly to pristine source (alone and stacked with DF-3755's fix), compiles -Werror clean as a kernel object (make KERNBUILDDIR=/usr/obj/usr/src/sys/X86_64_GENERIC ni_dpm.o, see fix_build.log), and the harness [B] path shows enable refused with no fault.

DF-3754 — Verdict

Verdict: REPRODUCED (source-level + harness) — NULL-deref panic, no escalation (deterministic NULL, no attacker-controlled offset)

radeon (Northern Islands) twin of si DF-3610 / ci DF-3646.

Bug confirmation

rdev->pm.dpm.boot_ps is assigned in exactly one place on the ni parse path — ni_parse_pplib_non_clock_info():

ni_dpm.c:3914   if (rps->class & ATOM_PPLIB_CLASSIFICATION_BOOT)
ni_dpm.c:3915       rdev->pm.dpm.boot_ps = rps;

That function is only reachable inside the per-state block of ni_parse_power_table() guarded by if (power_info->pplib.ucStateEntrySize - 1) (ni_dpm.c:4018). ni_parse_power_table() never verifies that a boot state was found and returns 0 as long as the header parses. Crafted-VBIOS shapes that leave boot_ps == NULL while parsing "succeeds":

1. ucNumStates == 0 — the state loop is a no-op, num_ps = 0;
2. ucStateEntrySize == 1 — the whole per-state block is skipped, so rdev->pm.dpm.ps[i].ps_priv also stays NULL for every state and the non-clock info (BOOT classification) is never parsed;
3. ucNumStates >= 1 but no state carries ATOM_PPLIB_CLASSIFICATION_BOOT (0x0008) in usClassification.

The consumer chain has no guard anywhere:

radeon_pm.c:1448     radeon_dpm_init(rdev);                 // return IGNORED
radeon_pm.c:1449     current_ps = requested_ps = boot_ps;   // NULL ok'd
radeon_pm.c:1453     ret = radeon_dpm_enable(rdev);
ni_dpm.c:3589        struct radeon_ps *boot_ps = rdev->pm.dpm.boot_ps;
ni_dpm.c:3641        ret = ni_init_smc_table(rdev);
ni_dpm.c:1943          radeon_boot_state = rdev->pm.dpm.boot_ps;   // NULL
ni_dpm.c:1975          ni_populate_smc_initial_state(rdev, NULL, table);
ni_dpm.c:1683            struct ni_ps *initial_state = ni_get_ps(NULL);
ni_dpm.c:733-735         return rps->ps_priv;    // read at NULL+0x28 -> panic

offsetof(struct radeon_ps, ps_priv) == 0x28 (radeon.h:1342-1356, LP64). Later NULL derefs on the same pointer: ni_dpm.c:3657 (ni_populate_mc_reg_table(rdev, boot_ps)), ni_dpm.c:3673 (ni_populate_smc_tdp_limits), ni_dpm.c:3698 (ni_update_current_ps), ni_dpm_disable:3738. The ps_priv-NULL variant (shape 2) additionally faults on the first power-state change: ni_dpm_pre_set_power_state:3771 -> ni_update_requested_ps:3576/3581 (ni_pi->requested_ps = *new_ps with new_ps == NULL, fault at 0x0), and in ni_dpm_print_power_state:4282.

DPM is default-enabled for the NI asics (BARTS/TURKS/CAICOS/CAYMAN/ARUBA, radeon_pm.c:1546-1572: radeon_dpm = -1 auto -> PM_METHOD_DPM whenever rlc/smc firmware is present — radeonkmsfw_* modules ship in /boot/kernel).

Harness confirmation

run.log:

[A] ... child died from signal 11: read at NULL+0x28
    >>> kernel: page-fault at 0x28 -> panic during DPM enable <<<
[A2] ... child died from signal 11: read at NULL+0x0
    >>> kernel: page-fault at 0 -> panic on first state change <<<
[B] Fixed path ... rc=-EINVAL (DPM enable refused, no dereference)

The harness builds a synthetic VBIOS PowerPlayInfo table, runs a verbatim replica of ni_parse_power_table's walk (including the ucStateEntrySize - 1 promotion quirk) over it, then executes the real consumer call graph; the forked children take SIGSEGV at exactly the predicted fault addresses (0x28 and 0x0) — the in-kernel equivalent is an unrecoverable page fault / panic during DPM enable.

Trigger conditions (not met on this guest)

1. AMD NI (Barts/Turks/Caicos/Cayman/Aruba) GPU with radeon DPM — the audit QEMU guest is virtio-only (no 0x1002 PCI device; verified in env.txt).
2. radeon.ko loaded and DPM enabled (default for NI).
3. Crafted VBIOS (reflash / KVM passthrough with custom ROM / supply-chain).

Exploit chain

None — the faulting pointer is fully deterministic NULL; there is no attacker-controlled offset or content. Pure boot-time DoS (panic) with a malicious VBIOS. Same conclusion as the si/ci twins.

Fix validation

fix.diff (guard in ni_dpm_enable, mirrors si DF-3610's fix): git apply/patch -p1 clean against pristine source — alone and stacked with DF-3755's fix; compiles -Werror clean as a kernel object (make KERNBUILDDIR=/usr/obj/usr/src/sys/X86_64_GENERIC ni_dpm.o, full CFLAGS in fix_build.log); harness [B] shows enable refused, no fault.

fix_status: fixed (compile + harness-level); live HW boot test impossible on this guest.

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.