Disable path programs count=0 + reload while leaving AMDSB_WD_RUN armed — kern.watchdog.period=0 (and panic-path wdog_disable) never actually disarm the watchdog; a zero count under RUN may act as a 1-tick fuse per SB RRG countdown semantics
Summary
amdsb_watchdog never clears RUN: period==0 (the documented disabled state and panic-path input) programs COUNT=0 and strokes RELOAD with the timer still running - per SB RRG countdown semantics an armed zero count may fire on the next tick, turning disable into a hard reset. Speculative (datasheet-ambiguous, ichwd shares the idiom); the correct disable idiom exists but is only used on detach. timeout==0->real-disable fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4805 · 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 1.2 KB | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
root: sysctl kern.watchdog.period=0 on armed hardware -> 'wdog: Disabled watchdog(s)' but timer keeps running with COUNT=0 -> possible hard reset ~1 tick later
Evidence (decisive lines)
findings/poc/DF-4805/ (this verdict)
Verdict
Speculative (datasheet-ambiguous zero-count edge), hardware-gated: amdsb_watchdog never clears AMDSB_WD_RUN - for period==0 (kern_wdog's documented 'disabled' state and the sole input of panic-path wdog_disable) it programs COUNT=0, skips re-enable, and strokes RELOAD leaving the timer RUNNING with count 0; per SB RRG countdown semantics an armed zero count may act as a 1-tick fuse, turning an explicit disable into a hard reset. The correct disable idiom (amdsbwd_tmr_disable) exists and is used only on detach. Sibling ichwd shares the write-0-and-reload idiom (benign on Intel TCO at least). Distinct from DF-1890/2540 (overflow-derived count=0). timeout==0 -> real-disable fix.
No comments yet.