# DF-2535 — OOB read / panic in mpt_disable_lun via wildcard LUN

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

## Hardware gate

No LSI Logic MPT HBA in guest: `kldstat` shows only kernel/ehci/xhci; `pciconf -l`
shows no LSI device. mpt target-mode LUN enable/disable is never exercised.

## Source trace (confirmed real bug)

**File:** `sys/dev/disk/mpt/mpt_cam.c:4335`

```c
for (i = 0; i < MPT_MAX_LUNS; i++) {
    if (mpt->trt[lun].enabled) {   // line 4335: TYPO — should be trt[i]
        break;
    }
}
```

The loop iterates with `i` but reads `mpt->trt[lun]` (the function parameter)
instead of `mpt->trt[i]`. When invoked with wildcard LUN (`CAM_LUN_WILDCARD=0xFFFFFFFF`)
together with wildcard target — a valid `XPT_EN_LUN` combination accepted at line
4322 — `lun` is `0xFFFFFFFF`, so `mpt->trt[0xFFFFFFFF].enabled` is a ~100GB OOB
read that faults the kernel and panics deterministically. The sibling function
`mpt_scsi_tgt_atio` at line 5038 correctly short-circuits `lun >= MPT_MAX_LUNS`;
`mpt_disable_lun` has no such guard before the buggy loop.

## Fix

Changed `mpt->trt[lun].enabled` to `mpt->trt[i].enabled` in the loop body.
See `fix.diff`.

## Impact (on HW that has the HBA)

Medium — deterministic kernel panic from XPT_EN_LUN with wildcard target+LUN.