# DF-1088 — CAM pass-through (`/dev/passN`) missing CCB flag validation

## Build

```
cc -o df1088_trigger df1088_trigger.c
```

## Run

```
# unprivileged (demonstrates the privilege gate)
./df1088_trigger

# privileged (demonstrates the CCB-shape bug)
su root -c ./df1088_trigger
```

## Expected (bug present)

- **Unprivileged**: `open /dev/pass0` fails with `Permission denied` (devfs
  mode 0600) — the trigger is privilege-gated.
- **Root (unpatched kernel)**: `CAMIOCOMMAND` with `CAM_DIR_IN | CAM_DATA_PHYS`
  and `cdb_len=255` returns **0** — the kernel forwarded the dangerous CCB
  to the SIM without stripping or rejecting the flags, and did not clamp
  `cdb_len` to `IOCDBLEN` (16). The signature line is:
  `[root] BUG: kernel forwarded attacker physical pointer to SIM without rejection (DF-1088 present)`

## Expected (after fix)

- **Root (patched kernel)**: `CAMIOCOMMAND` returns `-1, errno=EINVAL` —
  `passsendccb` rejects the dangerous flags / over-long CDB at the head of
  the function. Signature:
  `[root] FIXED: kernel rejected dangerous CCB flags (DF-1088 patch present)`

## Static verification

```
sh verify.sh
```

runs 7 source-tree grep checks that pin the exact buggy line and constants.

## Bug shape

`passsendccb` at `sys/bus/cam/scsi/scsi_pass.c:565-568` gates
`cam_periph_mapmem()` purely on `(flags & CAM_DATA_PHYS) == 0` but **never
strips the flag** and never rejects it; the kernel-internal XPT path
(`cam_xpt.c:1133`) **does** reject `CAM_DATA_PHYS` for `XPT_DEV_MATCH`. A
user-supplied CCB with `CAM_DATA_PHYS` therefore bypasses the
`cam_periph_mapmem` useracc/MAXPHYS/bounce-buffer path and reaches the SIM
with `csio.data_ptr` interpreted as a physical address for DMA. The same
function also fails to clamp `csio.cdb_len` to `IOCDBLEN` (16) for inline
CDBs, so `cdb_len=255` makes the SIM read 255 bytes from the 16-byte
`cdb_bytes[]` array, over-reading adjacent `union ccb` fields including
the kernel `msg_ptr` / `data_ptr`.

## Impact / preconditions

The device requires `caps_priv_check_self(SYSCAP_RESTRICTEDROOT)` and
`securelevel <= 1` to open (`scsi_pass.c:308,335`), and `/dev/passN` is
mode 0600 in the default install. The bug is therefore **not directly
reachable by an unprivileged user on a default install**; impact requires
either jail-granted `RESTRICTEDROOT` with `/dev/passN` exposed, or a
process already holding the `RESTRICTEDROOT` capability. The CVSS vector
in the finding reflects this (`AV:L/PR:L ...`).