DF-4098 — btdone/btreset panic() on host-adapter-fed bytes

Verdict: REPRODUCED (two independent panic sites, both captured)

Same rig class as DF-2429 (see DF-2429/README.md): production handlers resolved from the running kernel image and dispatched over a fabricated post-attach softc; the virtual firmware writes status bytes into the CCB DMA memory and the register file exactly as a MultiMaster HBA would.

Build

./push_rig.sh

Run (each on a fresh boot)

sh run_panic_btdone.sh    # site 1: btdone btstat panic
sh run_panic_btreset.sh   # site 2: btreset DIAG_ACTIVE panic

Expected output

1. run_panic_btdone.sh: a perfectly valid I/O CCB (normal TUR, cmd_len=6, queued ACTIVE through the real XPT path) is completed by the HBA with BMBI_ERROR + btstat=BTSTAT_INVALID_ACTION_CODE (0x15) — a single device-fed byte — and production btdone executes panic("bt9: Invalid Action code") at bt.c:1517 while holding bt->lock. panic_btdone.txt has the backtrace (btdone+0x4d3).
2. run_panic_btreset.sh: with the virtual STATUS_REG holding DIAG_ACTIVE (0x80) stuck, production btreset(hard) waits 5s for diagnostics to start (passes), then 10s for DIAG_ACTIVE to drop, and panics at bt.c:1650-1651: panic: bt9: btreset - Diagnostic Active failed to drop. status = 0x80 (panic_btreset.txt, btreset+0x266). ~15s of DELAY polling then panic.

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.