# DF-2521 — trm_action bcopy of user-controlled cdb_len into 12-byte CmdBlock

## Verdict: NOT REPRODUCED (HW-gated) — source bug CONFIRMED

## Hardware gate

No Tekram DC395 SCSI HBA in guest: `kldstat` shows only kernel/ehci/xhci; `pciconf -l`
shows no Tekram PCI device.

## Source trace (confirmed real bug)

**File:** `sys/dev/disk/trm/trm.c:591-610` (trm_action)

```c
pSRB->ScsiCmdLen = pcsio->cdb_len;                          // line 591
...
if ((pccb->ccb_h.flags & CAM_CDB_POINTER) != 0) {
    bcopy(pcsio->cdb_io.cdb_ptr, pSRB->CmdBlock, pcsio->cdb_len);   // line 598-599
} else
    bcopy(pcsio->cdb_io.cdb_bytes, pSRB->CmdBlock, pcsio->cdb_len); // line 609-610
```

`CmdBlock` is `u_int8_t[12]` (`trm.h:145`). `cdb_len` is `u_int8_t` (max 255)
propagated verbatim from userland. With `CAM_CDB_POINTER`, the source is an
attacker-controlled user buffer. `cdb_len > 12` writes past CmdBlock into
`Segment0`, `Segment1`, `pNextSRB`, `pSRBDCB`, `SgSenseTemp`, `pSRBSGL` —
corrupting SRB-list and DMA pointers with attacker data.

## Fix

Added `if (pcsio->cdb_len > sizeof(pSRB->CmdBlock))` early-return check before the
bcopy. See `fix.diff`.

## Impact (on HW that has the HBA)

High — heap corruption of SRB struct via pass(4) with `cdb_len=255`. Operator-group
`/dev/passN` access suffices.