Summary

Abort/term are no-op stubs, poll is empty, and aac_timeout only prints - a stalled adapter/target consumes one aac_command/FIB per timeout with CAM's escalation unable to reclaim any, until the pool exhausts and all controller I/O wedges. Hw-gated; certain from trace. No one-line fix (needs firmware abort FIB integration) - mitigation documented.

PoC verification

Evidence pack

findings/poc/DF-4720 · 3 files

File	Type	Size
README.md	—	1.6 KB	↓ raw
verdict.json	—	1.5 KB	view raw
manifest.json	—	522 B	view raw

README.md

↓ download raw

DF-4720 — aac_cam: XPT_ABORT/XPT_TERM_IO are decorative stubs and aac_timeout only logs → timed-out CAM CCBs and their FIBs leak until the command pool is exhausted

Root cause (code trace; hw-gated — no AAC adapter in the QEMU guest)

aac_cam_abort_ccb() / aac_cam_term_io() return CAM_UA_ABORT / CAM_UA_TERMIO and do nothing (sys/dev/raid/aac/aac_cam.c:681-691). The XPT_ABORT ccb itself is completed, but the target ccb is never cancelled: no abort FIB is sent to the adapter, no aac_command is released, the ccb is never completed — it hangs off cm->cm_private forever.
aac_timeout() (sys/dev/raid/aac/aac.c:2323-2350) traverses aac_busy, prints "COMMAND ... TIMEOUT", sets AAC_CMD_TIMEDOUT — and reaps nothing ("bitch about late commands once only").
aac_cam_poll() is an empty function (aac_cam.c:526-533), so the CAM timeout path has no recovery hook either.

Net effect: any command the (faulty or malicious-target-stalled) adapter fails to complete consumes one aac_command/FIB permanently. CAM error recovery escalates (abort → reset) but every escalation is a no-op in this driver, so a device that stalls N commands exhausts the FIB pool; from then on all I/O on the controller wedges (the AAC_EVENT_CMFREE machinery never fires because commands never return). Same terminal state as DF-3819's ioctl-side hang, reached from ordinary disk I/O.

No local one-line fix (needs a firmware abort FIB protocol integration); recommend at minimum completing timed-out ccbs with CAM_CMD_TIMEOUT and leaking-or-reaping the command deterministically.

Not runtime-verified: no AAC hardware in the QEMU guest.

Fix verification

not_testable

per-fix-DF-4720

Detail

Exploit chain

stalled/faulty target behind AAC -> command timeouts -> abort/reset escalations are no-ops -> FIB pool exhaustion -> controller I/O wedge (system DoS until reboot)

Evidence (decisive lines)

code trace: aac_cam.c:681-691 (stubs), aac.c:2323-2350 (log-only timeout), aac_cam.c:526-533 (empty poll)

PoC changes

n/a

Verified recommended fix

implement command cancellation for the CAM path: send the adapter's abort FIB (or at minimum complete timed-out ccbs with CAM_CMD_TIMEOUT and take the adapter offline after draining), and make XPT_ABORT release the associated aac_command

Verdict

XPT_ABORT/XPT_TERM_IO are stubs (aac_cam.c:681-691) and aac_timeout (aac.c:2323) only logs, so a stalled adapter leaks one FIB per timed-out command until the pool is exhausted and all controller I/O wedges (same terminal state as DF-3819, reached from ordinary disk I/O). Certain from trace; hw-gated so not runtime-verified. No one-line fix; needs firmware abort integration.

XPT_ABORT/XPT_TERM_IO are decorative stubs and aac_timeout() only logs: timed-out CAM CCBs and their FIBs leak permanently until the command pool is exhausted (controller-wide I/O wedge)