β¬’ DragonFlyBSD Kernel Audit
← triage Β· dashboard
DF-4804

amdsbwd hardware watchdog is never deactivated on reboot/halt (nor on panic by default): shutdown handler #if 0'd and no framework hook fires β€” default-auto-armed 30s timer hard-resets machines mid-POST/dump and can reset-loop long-boot hosts

Summary

Shutdown method compiled out; the only wdog_disable is inside panic() under off-by-default WDOG_DISABLE_ON_PANIC; kern_wdog auto-arms 30s at every attach by default - any reboot/halt/panic on AMD SB hosts races a 15-30s fuse through POST/loader/dump (hard reset mid-reboot, reset loops, truncated dumps). Availability only. Dedicated shutdown method (tmr_disable) fix.

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-4804 Β· 1 files
FileTypeDescriptionSize
verdict.json file 1.2 KB view raw

Fix verification

not_testable
per-fix-DF-4804

Confirmed kernel references

Detail

Exploit chain

boot with amdsbwd loaded (auto-armed 30s) -> reboot -> POST+loader exceeds remaining window -> hard reset mid-POST -> possible reset loop; ResetStatus latches 'Previous Reset was caused by Watchdog'

Evidence (decisive lines)

findings/poc/DF-4804/ (this verdict)

Verdict

Hardware-gated availability defect: the driver's shutdown method is #if 0'd (amdsbwd.c:112-114) and the only kernel-side wdog_disable() fires solely inside panic() under off-by-default WDOG_DISABLE_ON_PANIC - while kern_wdog auto-arms 30s at every attach by default. On AMD SB600/7xx/8xx/FCH hosts any reboot/halt/panic races a 15-30s hardware fuse through POST/loader/dump: long-POST hosts hard-reset mid-reboot and can reset-loop; crash dumps truncate ~15-30s in. No memory-safety impact. Dedicated amdsbwd_shutdown (tmr_disable) fix authored; framework alternative = shutdown_final hook calling wdog_disable after dumps.