# DF-4099 VERDICT — unknown comp_code leaks BCCB + CAM command permanently

## Bottom line

**REPRODUCED.**  When the host adapter completes a mailbox with a
comp_code the switch at bt.c:1451-1608 does not handle (only 0x00-0x04
have cases; there is no default), production `btdone` falls off the
switch and returns after having already executed `callout_stop` at
bt.c:1449.  Observed live on the production handler:

```
compx id=5 0x42 (BMBI_ERROR-shaped completion, unknown code 0x42)
[snap 3s later] flags=0x1 (ACTIVE)  on_pending=1  timer=0
                comp=0  ccb_status=0x200 (CAM_SIM_QUEUED)  map=1
```

The command never completes (comp stays 0 forever), the BCCB never
returns to `free_bt_ccbs`, and its timeout is already stopped — the
command is leaked irrevocably.  Repeating for each BCCB leaks them all;
the exhaustion demo in run.log ends with `active=11 pending=11`
permanently leaked and the next `queue io` returning `bccb=0x0`
(btgetccb NULL → CAM_REQUEUE_REQ + resource_shortage + simq freeze) —
every subsequent I/O on the bus wedges.  (Some of the 14 exhaustion
iterations EINVAL'd on the rig side due to devq dispatch pacing; 11
BCCBs leaked is past any doubt, and the mechanism is identical.)

## Root cause (path:line)

- bt.c:1451-1608 — `switch (comp_code)` with no `default`; comp_code is
  a device-fed `u8` (btreg.h:466-472 defines only 0x00-0x04).
- bt.c:1449 — `callout_stop(&bccb->timer)` already executed, so no
  timeout will ever rescue the leaked command.

## Honest correction to the finding text

`bus_dmamap_unload` runs at bt.c:1403 BEFORE the switch, so the
dmamap of a data-carrying CCB *is* unloaded even on the fall-through
path ("dmamap stays loaded" in the summary is incorrect).  The BCCB,
the CAM command and the timeout are still leaked exactly as claimed.

## Impact

Hostile or buggy HBA firmware (or a compromised HBA) wedges all I/O on
the bus with a handful of mailbox bytes — permanent DoS with no
recovery except a reboot.

## Fix validation

`fix.diff` adds a `default` arm that completes the CCB with
CAM_REQ_CMP_ERR via the normal tail (btfreeccb + xpt_done).  Patched
bt.c+btreg.h compile clean with the kernel's own flags under -Werror
(`FIXED-COMPILES-CLEAN`).  No runtime A/B kernel build (leak/DoS 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.