DF-3972 — NULL-pointer dereference of rdev->pm.dpm.boot_ps in btc_dpm_enable/btc_dpm_disable (crafted-VBIOS Barts/Turks/Caicos)

• File: sys/dev/drm/radeon/btc_dpm.c (pass 2)
• Class: CWE-476 NULL deref → kernel panic (Medium)
• Family: radeon DPM boot_ps twins (DF-3610 si / DF-3646 ci / DF-3754 ni / DF-3953 kv) — this is the btc (Barts/Turks/Caicos) sibling; distinct enable path, distinct file. Known DF-1314 (mc_reg_table off-by-one) is unrelated.

Build / Run / Expected

Hardware-gated: requires an AMD Barts/Turks/Caicos (NI-generation discrete GPU) whose VBIOS PowerPlayInfo table either (a) contains no state with ATOM_PPLIB_CLASSIFICATION_BOOT set, or (b) declares ucStateEntrySize <= 1 so the non-clock-info (classification) parse is skipped entirely.

No buildable PoC exists without the card: the trigger data lives in the GPU ROM image, parsed by rv7xx_parse_power_table() at driver attach. See VERDICT.md for the line-level trace.

Root cause (source-level, certain)

1. rv7xx_parse_power_table() — sys/dev/drm/radeon/rv770_dpm.c:2271-2329 — is the only code that sets rdev->pm.dpm.boot_ps for BTC asics. It does so inside rv7xx_parse_pplib_non_clock_info() (rv770_dpm.c:2172-2173), which is only reached when power_info->pplib.ucStateEntrySize - 1 != 0 (rv770_dpm.c:2304) and a parsed state carries the BOOT classification bit. A VBIOS with no BOOT-classified state (or ucStateEntrySize<=1) leaves boot_ps == NULL while btc_dpm_init() still returns 0 (parse "succeeded").
2. radeon_pm_init_dpm() — sys/dev/drm/radeon/radeon_pm.c:1448 — ignores the return of radeon_dpm_init(rdev) (= btc_dpm_init) and unconditionally calls radeon_dpm_enable(rdev) (line 1453). There is no boot_ps validation anywhere on the path.
3. btc_dpm_enable() — sys/dev/drm/radeon/btc_dpm.c:2373-2488 — takes struct radeon_ps *boot_ps = rdev->pm.dpm.boot_ps; (2377) and dereferences it at: - 2446 btc_init_smc_table(rdev, boot_ps) → cypress_populate_smc_initial_state(rdev, NULL, table) → rv770_get_ps(NULL) then initial_state->low.mclk (cypress_dpm.c:1242,1266) → NULL-page read. - 2451 cypress_populate_mc_reg_table(rdev, boot_ps) - 2485 btc_update_current_ps(rdev, rdev->pm.dpm.boot_ps)
4. btc_dpm_disable() — btc_dpm.c:2490-2527 — same NULL at 2526 (btc_update_current_ps).
5. Also note radeon_pm.c:1449 assigns current_ps = requested_ps = boot_ps (NULL is tolerated there until later consumers run).

DPM is enabled by default (radeon.dpm=1 default on this family), so a crafted/flashed VBIOS panics the kernel at drm attach — local DoS with physical access (or a supply-chain-flashed card).

Fix

Validate boot_ps after parse (upstream-style guard) — see fix.diff.

VERDICT — DF-3972

status: inconclusive (hardware-gated; source-level certainty: certain) impact: none demonstrated on available hardware; real-world impact = local kernel panic (DoS) at drm attach on Barts/Turks/Caicos with crafted VBIOS

Why inconclusive, not false-positive

The QEMU guest (env.txt) has no AMD GPU: only Intel/Red Hat QEMU PCI devices, no /dev/dri, no drm modules. The bug's trigger bytes live in the GPU's ATOM BIOS PowerPlayInfo table; there is no way to feed a radeon VBIOS to the guest's non-existent radeon device, and radeon.ko is not even loadable there. Per audit convention for the DF-3610/3646/3754/3953 family this is recorded as inconclusive with confidence: certain at source level.

Reproduction reasoning (line-level, no hardware needed)

Attacker model: physical access (or malicious reseller/reflash) supplying a GPU ROM whose _ATOM_PPLIB_POWERPLAYTABLE:

• ucNumStates >= 1, and either
• no state's _ATOM_PPLIB_NONCLOCK_INFO.usClassification has ATOM_PPLIB_CLASSIFICATION_BOOT, or
• ucStateEntrySize == 1 (skips the whole per-state parse block, rv770_dpm.c:2304-2325).

Trace:

radeon_pm_init (radeon_pm.c:1505)
 └─ radeon_pm_init_dpm (radeon_pm.c:1422)
     ├─ radeon_dpm_init(rdev)            # 1448 — btc_dpm_init, RETURN IGNORED
     │   └─ btc_dpm_init (btc_dpm.c:2549)
     │       └─ rv7xx_parse_power_table (rv770_dpm.c:2271)
     │           └─ boot_ps NEVER set  (2172 only under classification parse)
     ├─ current_ps = requested_ps = boot_ps   # 1449, NULL ok
     ├─ radeon_dpm_setup_asic → btc_dpm_setup_asic (btc_dpm.c:2529)  # no boot_ps use
     └─ radeon_dpm_enable → btc_dpm_enable (btc_dpm.c:2373)
         └─ 2377 boot_ps = rdev->pm.dpm.boot_ps == NULL
         └─ 2446 btc_init_smc_table(rdev, NULL) (btc_dpm.c:1624)
             └─ 1661 cypress_populate_smc_initial_state(rdev, NULL, table)
                 └─ cypress_dpm.c:1242 rv770_get_ps(NULL) == NULL->ps_priv → #PF

rv770_get_ps() is a plain container_of-style cast (rps->ps_priv), so the first dereference reads address ~0x0 + offsetof(ps_priv) on the NULL page → kernel page fault → panic. This is the exact enabling sequence already proven for the ni twin (DF-3754, reproduced/panic on that batch's harness).

Not a duplicate

DF-3754 (ni_dpm.c) covers Cayman's ni_dpm_enable; DF-3610/3646/3953 cover si/ci/kv. Barts/Turks/ Caicos use btc_dpm_enable via the btcd.h asic table — a different function and file, and the orchestrator's pass-2 checklist explicitly requested it. DF-1314 (this file's known finding) is the mc_reg_table off-by-one — unrelated.

Fix validation

fix_status: not_testable — no Barts-class GPU on the guest; a kernel rebuild cannot exercise the path. fix.diff authored against the read-only sys/ tree (guard + error propagation), mirroring the upstream si/ci/kv hardening pattern.

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.