# VERDICT - DF-4272 (dcn_bw_notify_pplib_of_wm_ranges NULL pp_smu deref)

**Status: untested** - the audit guest has no AMD DCN1 (Raven) GPU
(env.txt); the code path is source-certain.

## Trace

1. `dcn_bw_notify_pplib_of_wm_ranges()` (dcn_calcs.c:1401):
   `struct pp_smu_funcs_rv *pp = dc->res_pool->pp_smu;`
2. First dereference of `pp`: `if (!pp->set_wm_ranges)` (dcn_calcs.c:1406) -
   `pp` itself is never NULL-checked.
3. Sole assignment: `pool->base.pp_smu = dcn10_pp_smu_create(ctx);`
   (dcn10_resource.c:1352), whose implementation returns NULL on kzalloc
   failure (dcn10_resource.c:858-865). No NULL check follows the create.
4. Unconditional call site (unless the debug flag
   `disable_pplib_wm_range` is set): dcn10_resource.c:1353-1357, inside
   `dcn10_resource_construct()` during driver probe. Second site:
   dcn10_hw_sequencer.c:2303 (`optimize_shared_resources`), reached later in
   DC bring-up.

## Impact

NULL pointer read → panic during amdgpu probe under memory pressure on
DCN1-bearing APUs (Raven). Trigger is environmental (kzalloc OOM at the
wrong instant), not attacker-directed in the usual sense; the guest has no
such hardware so no reproduction is possible. Low severity, certain code
path, speculative trigger. Note: the same latent pattern exists in the
upstream Linux DC code of this vintage.

## Fix

One-line guard (fix.diff). A NULL-check-only change: no behavioral
difference on the success path.

## Fix validation

Not possible on this guest (no Raven GPU). fix_status = not_testable.

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