# DF-4098 VERDICT — hostile/wedged-controller panic family in btdone/btreset

## Bottom line

**REPRODUCED at both cited panic sites**, with the production code
executing from the shipped kernel image:

- **btdone site** (bt.c:1517): a valid, normally-queued I/O CCB whose
  completion mailbox carries `btstat = BTSTAT_INVALID_ACTION_CODE`
  (0x15) — one host-adapter-fed byte — panics the kernel while the
  driver holds `bt->lock`:
  `panic: bt9: Invalid Action code`, backtrace `btdone+0x4d3`
  (panic_btdone.txt).  The sibling panics at bt.c:1520 (INVALID_OPCODE,
  exercised in DF-4097), bt.c:1524 and bt.c:1527 are the same pattern
  (four `panic()` calls switching on `bccb->hccb.btstat`, a byte in CCB
  DMA memory the adapter owns).
- **btreset site** (bt.c:1650-1651): with STATUS_REG scripting
  DIAG_ACTIVE stuck (wedged/hardware-failing controller — exactly the
  situation a reset is meant to recover from), production
  `btreset(hard)` panics after the 10s wait:
  `panic: bt9: btreset - Diagnostic Active failed to drop. status =
  0x80`, backtrace `btreset+0x266` (panic_btreset.txt).

## Live evidence

run_panic_btdone.log + panic_btdone.txt:

```
[rig] COMP: firmware writes completion: bccb=0xfffff801167df620
       comp_code=0x04 btstat=0x15 sdstat=0x00 -> production btdone()
panic: bt9: Invalid Action code
btdone() at btdone+0x4d3 0xffffffff8042e763
```

run_panic_btreset.log + panic_btreset.txt:

```
[rig] BTRESET: production btreset(hard=1)
panic: bt9: btreset - Diagnostic Active failed to drop. status = 0x80
btreset() at btreset+0x266 0xffffffff8042f606
```

## Root cause (path:line)

- bt.c:1517, 1520, 1524, 1527 — `panic()` on `bccb->hccb.btstat`
  values written into CCB DMA memory by the host adapter.
- bt.c:1650-1651 — `panic()` when DIAG_ACTIVE never drops within 10s.
- Both reachable from the shared interrupt path (`bt_intr` →
  `bt_intr_locked` → `btdone`) and from timeout recovery
  (`bttimeout` → `btreset`).

## Impact

Any BusLogic controller that misbehaves (PCI error, wedged firmware, or
a malicious/compromised HBA — the DF-4042/4043 amd hostile-target
family analogue) converts one status byte into an immediate kernel
panic.  Local DoS from device-fed state; recovery is impossible because
the driver dies instead of completing the command with an error.

## Fix validation

`fix.diff` converts all five panic sites into `device_printf` +
error completion (CAM_REQ_CMP_ERR / ETIMEDOUT).  Patched bt.c+btreg.h
compile clean with the X86_64_GENERIC kernel flags under -Werror
(`FIXED-COMPILES-CLEAN`, `bt.fixed.o`).  No runtime A/B kernel build
(panic class, not memory corruption; not mandated).

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.