{
  "finding_id": "DF-4717",
  "status": "untested",
  "reproduced": 0,
  "impact": "none",
  "confidence": "certain",
  "verdict": "XPT_RESET_DEV submits its FIB with a stale Header.Command (set only for XPT_SCSI_IO at aac_cam.c:452-453; aac_release_commands re-init at aac.c:1395-1407 never clears it), so device resets are dispatched by the firmware under an unrelated opcode (protocol confusion / failed error recovery; worst case container-ioctl misinterpretation). Runtime verification impossible on this guest: Adaptec AAC is PCI hardware not emulated by QEMU. Fix by code trace: set the command on the common path (fix.diff).",
  "exploit_chain": "failing/target device behind an AAC controller -> CAM periph timeout -> XPT_RESET_DEV -> FIB sent under stale opcode -> reset lost / adapter command confusion",
  "evidence": "code trace: aac_cam.c:432-499 (only SCSI_IO sets Command), aac_cam.c:511-518 (XferState/Size set, Command untouched), aac.c:1395-1407 (re-init omits Header.Command)",
  "kernel_refs": [
    "sys/dev/raid/aac/aac_cam.c:452",
    "sys/dev/raid/aac/aac_cam.c:488",
    "sys/dev/raid/aac/aac.c:1395"
  ],
  "poc_changes": "n/a (no seeded PoC)",
  "attempts": 0,
  "guest_uname": "",
  "runtime_sec": 0,
  "guest_dirty": 0,
  "build_cmd": "",
  "run_cmd": "",
  "code_hash": "",
  "notes": "hw-gated: no AAC emulation in QEMU; classification by source trace. Same command pool is shared with aac.c ioctl paths (DF-3819 family) which is where exotic stale opcodes come from.",
  "recommended_fix": "assign fib->Header.Command on the common path before the func_code switch (fix.diff) or clear it in aac_release_command()"
}