# DF-4717 — aac_cam XPT_RESET_DEV sends the FIB under a stale Header.Command

## Root cause (code trace; hw-gated — no Adaptec adapter in the QEMU guest, runtime verification not possible)

`fib->Header.Command` is assigned ONLY in the `XPT_SCSI_IO` case of
`aac_cam_action()` (`sys/dev/raid/aac/aac_cam.c:452-453`). The
`XPT_RESET_DEV` case (`:488-496`) falls through to the common SRB setup
(`:501-521`) and sends the FIB without ever setting the command opcode.

`aac_release_command()`'s "re-initialize" (`sys/dev/raid/aac/aac.c:1395-1407`)
clears `XferState`, `StructType`, `Flags`, `SenderSize`,
`ReceiverFibAddress`, `SenderData` — **not `Header.Command`**. Every FIB
therefore carries the opcode of whatever previously used it (an earlier
ScsiPortCommand, but equally a ContainerCommand, ClusterCommand, AIF or
ioctl FIB routed through the same command pool).

Result: a device reset issued by CAM (XPT_RESET_DEV — issued by periph
error recovery on command timeouts, i.e. precisely when the adapter is
misbehaving) is submitted to the adapter as a *stale, unrelated* command
with a reset-SRB payload. The firmware dispatches on Header.Command, so
the reset is either silently mangled into a different operation (up to
container reconfiguration if the stale opcode maps to a container ioctl)
or ignored; aac_cam_complete() then interprets the response as an
aac_srb_response. The reset also obviously does not reset the device,
defeating CAM's error recovery escalation.

Threat: requires an AAC adapter (PCI) plus a failing/target device that
triggers CAM reset escalation; consequences are adapter-state corruption /
failed recovery. Device-dependent; not memory-unsafe in the host.

## Fix

Set `Header.Command` on the common path (both XPT_SCSI_IO and
XPT_RESET_DEV) — `fix.diff` moves the 64-bit selection before the
direction switch. Alternatively clear `Header.Command` in
`aac_release_command()`.