dc_clock_type_to_atom default path leaves *atom_clock_type uninitialized yet returns true — latent uninitialized-stack feed into ATOM setdceclock params (v2)
Summary
Default branch neither writes the output nor clears retCode while the consumer declares the variable uninit and copies it into the VBIOS command - unreachable today (enum exactly 2 members, driver-internal), live the moment the enum is extended. retCode=false fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4935 · 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 969 B | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
none today (enum-closed)
Evidence (decisive lines)
findings/poc/DF-4935/ (this verdict)
Verdict
Latent output-param contract violation (Info/speculative): the default branch ASSERTs without writing *atom_clock_type or clearing retCode - the function can return true with the output untouched, and the live consumer set_dce_clock_v2_1 declares the variable uninitialized and copies it into the VBIOS command. Unreachable today (the enum has exactly the two handled members, driver-internal source) - becomes a live uninit-stack-to-VBIOS feed the moment the enum is extended (DCN upstream added PIXELCLK for exactly this table). retCode=false-in-default fix.
No comments yet.