# DF-3672 — MPT_TAG_2_REQ() indexes tgt_cmd_ptrs[tag>>18] with NO bounds check in production kernels

**Severity: Medium (memcorrupt) — source-certain; runtime-gated on LSI FC target-mode hardware.**

## Build / Run (on a host that has an mpt(4) FC adapter in target role)

```sh
cc -O -o mpt_tag_oob mpt_tag_oob.c          # DragonFly, with /usr/src present
./mpt_tag_oob /dev/passN                    # N = pass node on the mpt target-mode bus
```

Expected on vulnerable kernel: immediate kernel panic (wild `request_t *`
dereference) or, after heap grooming around the 2 KB `tgt_cmd_ptrs`
allocation, `mpt_tgt_dump_req_state()` printing attacker-chosen kernel
addresses/words to the console (`req %p:%u index %u ...` — mpt_cam.c:4371,
5187-5194).

## Why this guest cannot run it

- Kernel `X86_64_GENERIC` compiles mpt in (`sys/config/X86_64_GENERIC:93`,
  confirmed on the guest), but the QEMU guest has **no LSI (vendor 0x1000)
  PCI device** — `pciconf -lv | grep -c vendor=0x1000` = 0 — so no mpt
  softc ever attaches, no CAM bus registers, and no /dev/passN node on an
  mpt bus exists to submit the CCB through.
- The trigger is a plain unprivileged (operator-group) ioctl once such
  hardware is present; no IOC misbehaviour is required — the user supplies
  the bad tag directly.

See `env.txt`, `VERDICT.md`, `verdict.json`.