DF-4291 — atomctrl_get_voltage_evv() dereferences hwmgr->dyn_state.vddc_dependency_on_sclk without a NULL check

Pass-2 finding for sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c (the "(e) powerplay table glue — the hwmgr dyn_state field fills" item of the pass-2 brief). Not DF-1497 (that is the svi2 lookup NULL deref in this same file) — this is the dyn_state table pointer NULL deref.

The bug (ppatomctrl.c:1131, 1138, 1147)

int atomctrl_get_voltage_evv(struct pp_hwmgr *hwmgr, ...)
{
        ...
        for (entry_id = 0;
             entry_id < hwmgr->dyn_state.vddc_dependency_on_sclk->count;   /* :1131 */
             entry_id++) {
                if (hwmgr->dyn_state.vddc_dependency_on_sclk
                        ->entries[entry_id].v == virtual_voltage_id) {     /* :1132 */

hwmgr->dyn_state.vddc_dependency_on_sclk is initialized to NULL by the powerplay-table parser (processpptables.c:1213) and only filled when the VBIOS powerplay table v4+ carries a non-zero usVddcDependencyOnSCLKOffset (processpptables.c:1304-1310). The parser itself treats the field as nullable (processpptables.c:1341-1342: if (result == 0 && (NULL != hwmgr->dyn_state.vddc_dependency_on_sclk) && ...)), but atomctrl_get_voltage_evv does not.

Reachability: phm_get_voltage_evv_on_sclk() dispatches here for chip_id < CHIP_TONGA (smu_helper.c:571-572); its only caller is smu7_get_evv_voltages() (smu7_hwmgr.c:1760), invoked from smu7_hwmgr_backend_init() (smu7_hwmgr.c:2551) at driver attach — reached whenever the powerplay table is V0 or the lookup path fails (smu7_hwmgr.c:1742). A CI/KV-class card whose VBIOS powerplay table omits the VDDC-on-SCLK dependency sub-table ⇒ NULL->count ⇒ Fatal trap 12 kernel panic at attach/boot (CWE-476).

Reproduce

Not runnable on this guest (no AMD dGPU — env.txt). On hardware: VBIOS powerplay table with usVddcDependencyOnSCLKOffset == 0 on a pre-Tonga (CI/KV) part, boot → panic at amdgpu attach.

DF-4291 VERDICT — dyn_state.vddc_dependency_on_sclk NULL deref

Status: inconclusive (code-trace certain; guest has no AMD dGPU)

Trace

• ppatomctrl.c:1131 hwmgr->dyn_state.vddc_dependency_on_sclk->count — first deref, no NULL check anywhere in atomctrl_get_voltage_evv (ppatomctrl.c:1121-1160). Re-derefs at :1132, :1138, :1147.
• Parser contract proving NULL is expected:
• processpptables.c:1213 hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
• processpptables.c:1304-1310 filled only if 0 != powerplay_table4->usVddcDependencyOnSCLKOffset
• processpptables.c:1341-1342 the parser itself NULL-guards the same pointer (NULL != hwmgr->dyn_state.vddc_dependency_on_sclk) — the invariant "may be NULL" is established in-tree.
• Dispatch chain (chip < CHIP_TONGA only): smu7_hwmgr_backend_init (smu7_hwmgr.c:2535) → smu7_get_evv_voltages (smu7_hwmgr.c:2551→1693) → :1742 pp_table_version == PP_TABLE_V0 || !phm_get_sclk_for_voltage_evv(...) → :1760 phm_get_voltage_evv_on_sclk (smu_helper.c:565-582) → :571-572 chip_id < CHIP_TONGA ⇒ atomctrl_get_voltage_evv ⇒ NULL deref when the table pointer is NULL.
• Contrast: the sibling function in the same file, atomctrl_get_voltage_evv_on_sclk (ppatomctrl.c:1085), does not touch dyn_state — only the pre-Tonga EVV variant does.

Impact

Boot/module-load Fatal trap 12 NULL-deref panic (CWE-476) with a crafted/defective VBIOS on CI/KV-class hardware; Medium, DF-1497 band. Not runnable on this guest (no AMD dGPU) ⇒ inconclusive, trace-certain.

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.