Dispatch entries bypassing hwmgr->smu_lock (pp_get_power_profile_mode, pp_set_clockgating_by_smu, pp_dpm_powergate_gfx/mmhub/acp/sdma) race the smu_lock-protected pp_table reset path that frees the hwmgr backend
Summary
Every mutating dispatch entry takes smu_lock, but six do not - including pp_get_power_profile_mode, reachable by ANY user via the world-readable sysfs attribute. The pp_table write path holds smu_lock across amd_powerplay_reset whose backend_fini kfrees and NULLs hwmgr->backend before hw_init recreates it. An unlocked dispatch landing inside that window dereferences a NULL or just-freed backend - the profile-mode reader sprintf's backend fields to an unprivileged reader (NULL panic or freed-slab disclosure). Add smu_lock to the six entries + the missing pm_en check.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4367 Β· 2 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | file | 185 B | β raw | |
| verdict.json | file | 892 B | view raw |
DF-4367
Hardware-gated finding - PoC skipped per contract. Source citations in the pass-2 result block.
Fix: take smu_lock in the six unlocked entries + add the missing pm_en check
Fix verification
not_testabletake smu_lock in the six unlocked entries + add the missing pm_en check
source-only
Confirmed kernel references
Detail
Exploit chain
[]
Evidence (decisive lines)
source-only; full path:line trace in pass-2 result block
Verdict
source-verified; hardware-gated (no AMD GPU on audit guest)
No comments yet.