# DF-4241 — VERDICT

**REPRODUCED** (kernel list corruption + double `xpt_done` → CAM completion panic; fix
validated on a rebuilt kernel).

## Chain, all production code

0. rig registers a real cam_sim over a fabricated post-attach softc (real bus_dma; free
   list built by production `dptallocccbs`); the sim's handlers are the shipped kernel's
   `dpt_action`/`dpt_poll`.
1. `./dfdpt_ctl queue` → `xpt_action` with a REAL `xpt_alloc_ccb`'d XPT_SCSI_IO →
   production `dpt_action` (0xffffffff80438010) → `dptexecuteccb` → dccb `X`
   (0xfffff801185b78e8) is `DCCB_ACTIVE`, on `pending_ccb_list`, callout armed,
   `ccb_h.status = CAM_SIM_QUEUED`, `ccb_dccb_ptr = X`.
2. `./dfdpt_ctl intr 0 1 0 0` (legit single status packet, hba_stat=0/scsi_stat=0/EOC=1,
   DMA'd into the sp by the "device"): production `dpt_intr` (0xffffffff80439670) maps the
   busaddr to X (only range-checked, dpt_scsi.c:1518-1527), completes it:
   `CAM_REQ_CMP`, `rig_done` fires (`comp=1`), `dptfreeccb` inserts X into the free list
   once. Everything clean.
3. `./dfdpt_ctl dupalias 0` — the device delivers a **duplicate** of the same packet.
   Production `dpt_intr` again maps X — still no `DCCB_ACTIVE` check — and:
   - `callout_stop` on the stale (already completed, CAM-owned) ccb's timeout;
   - `dptfreeccb(dpt, X)` with `state == DCCB_FREE`: no LIST_REMOVE, but
     `SLIST_INSERT_HEAD` runs again → **self-loop** (`head->next == head`, rig prints
     `SELFLOOP=1`, `dups=200/200` = unbounded walk, `free_dccbs` inflated to 1);
   - `xpt_done(ccb)` **a second time** → the completed ccb is re-enqueued on
     `sim_doneq`.
4. Still inside the same ioctl (rig lock held, so the CAM SWI cannot race the capture),
   two more real XPT_SCSI_IOs are queued: production `dptgetccb` pops the self-looped
   head twice → **both CCBs get the SAME dccb** (`SHARED=1`) — the shared-command-block
   UAF; the rig then releases the lock.
5. The CAM software-interrupt handler processes the corrupt `sim_doneq`:
   `panic: Bad link elm 0xfffff801185f0ec0 prev->next != elm` in `camisr_runqueue` —
   and 0xfffff801185f0ec0 is exactly the CCB from step 1 (`QUEUE id=0 ccb=...`).
   System down in DDB. (First observed serendipitously in an earlier boot —
   `run.2.log` — then reproduced cleanly with the capture-under-lock sequence —
   `run.log`.)

## Fix validation (fix.diff applied, kernel rebuilt + rebooted)

Same rig, same sequence (`fix_validation.log`):
- the duplicate packet now hits the added guard: `dpt9: status packet for inactive CCB
  ignored` (production `dpt_intr`, dpt_scsi.c:1551ff in the patched file), IRQ cleared,
  loop continues — no double free, no double `xpt_done`;
- free list healthy: `SELFLOOP=0 dups=1 walk=16 ctr=0`;
- no aliasing: the two subsequent queues got **different** dccbs
  (`0x...8e8` vs `0x...850`, `SHARED=0`);
- no panic: `dupalias` returned to userland (`DUPALIAS_RC=0`), guest stayed up;
- the legitimate completion path is unaffected (`comp=1`, `CAM_REQ_CMP` — captured in
  the same log).

## Threat model

`sp->ccb_busaddr` is DMA'd by the controller (dpt.h:523): a hostile device (or
passed-through/virtualized HBA) sends a duplicate/fabricated completion for any in-range
busaddr. The SMP variant in the finding (dpttimeout → dpt_intr racing the hardirq,
dpt_scsi.c:1696) is the same missing-in-flight-check root cause; the demonstrated
primitive (device-fed double completion) is the superset.

## Caveats

- The rig calls `dpt_intr` from an ioctl thread (not a hardirq) — irrelevant to the bug:
  the corruption happens inside `dpt_intr` proper, and the detonation happens in the
  CAM SWI thread exactly as it would from a real interrupt.
- The rig's duplicate is byte-identical to the legit packet, which is exactly the
  "duplicate completion" case; the fabricated-in-range-busaddr case (any other dccb) is
  the same code path with the same missing check.

## 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.