aac_disk_dump() consumes firmware-derived geometry with no host-side clamping: max_sectors==0 → infinite dump loop, sg_tablesize/SectorCount/BlockNumber overflow the FIB fields, single static dump map shared across controllers
Summary
Crash-dump path trusts controller-reported parameters never re-validated at this sink: fw max_sectors==0 wedges the dump loop post-panic (dump lost); oversized sg_tablesize writes SG entries past fib->data into the shared sync FIB; u16 SectorCount truncates 64MB maxio; u32 BlockNumber truncates >2TB. The DF-4797/4874 teardown family is KILLED for aac (detach refuses while open; no dsgone; no self-free). Clamp-at-acquisition + dump guards fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4894 · 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 1.1 KB | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
fw returns 0/oversized GETCOMMPREF -> panic -> dump spins forever or corrupts the sync FIB
Evidence (decisive lines)
findings/poc/DF-4894/ (this verdict)
Verdict
Crash-time hardening (Info; needs non-conforming aac firmware + a panic): aac_disk_dump consumes firmware-derived geometry with no host-side clamping - max_sectors==0 -> maxio=0 -> len=0 -> the dump loop never advances (post-panic hang, dump lost); sg_tablesize > FIB capacity writes nsegs aac_sg_entries past fib->data into the shared sync-fib area; SectorCount is u16 while maxio can reach 64MB (truncates mod 65536); BlockNumber u32 truncates >2TB dumps; the static dump map is shared across controllers. The DF-4797/4874 teardown family is KILLED for this driver (detach refuses while open; no dsgone; no self-free - traced in full). Clamp-at-acquisition + dump-loop guards fix.
No comments yet.