# 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.