# DF-4097 VERDICT — XPT_RESET_DEV converted to a malformed opcode-0 CCB

## Bottom line

**REPRODUCED, both halves.** (1) A CAM device reset dispatched through
the real `xpt_action`/production `btaction` path arrives at the host
adapter mailbox as an opcode **0x00 (INITIATOR_CCB)** CCB with
`cmd_len == 0`, `sense_len == 0` — the `INITIATOR_BUS_DEV_RESET` (0x81)
stored at bt.c:1062 is unconditionally overwritten by btexecuteccb's
`nseg == 0` branch (bt.c:1285).  (2) Conforming MultiMaster firmware
rejects such a CCB (BTSTAT_INVALID_OPCODE, 0x16) and production
`btdone` turns that device-fed status into
`panic: bt9: Invalid CCB Opcode code` (bt.c:1520) — captured with
backtrace in panic.txt.

## Live evidence

Clean run (run1_clean.log lines 3-10):

```
[snap] id=0 (XPT_SCSI_IO TUR):     hccb(op=0x00 cmd_len=6 ...) flags=0x1 timer=1
[snap] id=1 (XPT_RESET_DEV):       hccb(op=0x00 cmd_len=0 sense_len=0 ...)
```

Both CCBs went through the identical production path
(`xpt_action` → devq → `sim->sim_action` = production btaction).  The
reset CCB's opcode is 0x00 with an empty CDB — exactly the clobber.

Panic run (run_panic.log, panic.txt):

```
[rig] QUEUE done: id=0 bccb=0xfffff801167df620 opcode=0x00 cmd_len=0 ...
[rig] COMP: firmware writes completion: bccb=0xfffff801167df620
       comp_code=0x04 btstat=0x16 sdstat=0x00 -> production btdone()
panic: bt9: Invalid CCB Opcode code
btdone() at btdone+0x6cd 0xffffffff8042e95d
rig_ioctl() at rig_ioctl+0x1ee ...
```

## Root cause (path:line)

- sys/dev/disk/buslogic/bt.c:1062 — sets `hccb->opcode =
  INITIATOR_BUS_DEV_RESET` for XPT_RESET_DEV.
- sys/dev/disk/buslogic/bt.c:1284-1287 — `btexecuteccb`'s `nseg == 0`
  branch unconditionally overwrites the opcode with INITIATOR_CCB;
  XPT_RESET_DEV passes `btexecuteccb(bccb, NULL, 0, 0)` (bt.c:1070), so
  the reset path always lands here.
- Terminal consequence: bt.c:1520 panic on the firmware's rejection.

## Impact

On real bt(4) hardware, every CAM device reset (e.g. `camcontrol reset`)
is transmitted as a malformed CCB; error recovery is broken, and a
standards-conforming firmware reply panics the kernel.  Privileged
admin-triggerable panic + broken recovery.

## Fix validation

`fix.diff` preserves INITIATOR_BUS_DEV_RESET across the nseg==0 path.
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.