# DF-2484 — Untrusted IOC-supplied indices index raid_disks/raid_volumes

## 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. RAID arrays do not exist.

## Source trace (confirmed real bug)

**File:** `sys/dev/disk/mpt/mpt_raid.c` — five sites:

1. Line 414: `mpt_disk = mpt->raid_disks + raid_event->PhysDiskNum;`
2. Line 1155: `mpt_disk = mpt->raid_disks + vol_pg->PhysDisk[i].PhysDiskNum;`
3. Line 1309: `mpt_disk = mpt->raid_disks + vol_pg->PhysDisk[i].PhysDiskNum;`
4. Line 1405: `mpt_disk = mpt->raid_disks + ioc_disk->PhysDiskNum;`
5. Line 1436: `mpt_vol = mpt->raid_volumes + ioc_vol->VolumePageNumber;`

None of these compare the index to `raid_max_disks`/`raid_max_volumes`. The arrays
are sized by `MaxPhysDisks`/`MaxVolumes` (U8), but the indices are independently
supplied U8 values from different IOC config pages. A malicious/faulty IOC can
supply `PhysDiskNum=254` when the array has 2-8 entries → heap OOB write of kernel
pointer and u_int fields up to ~38KB past the array.

## Fix

Added `>= raid_max_disks`/`>= raid_max_volumes` bounds checks before each indexing
site. See `fix.diff`.

## Impact (on HW that has the HBA)

Medium — heap OOB read/write of kernel pointers and u_int fields via malicious IOC.