# DF-1242 — mrsas_complete_cmd SMID to index (OOB array access)

## Verdict: NOT REPRODUCED (dead code at runtime — no hardware)

## Mechanism (source-level, confirmed real)

`mrsas_complete_cmd()` at `sys/dev/raid/mrsas/mrsas.c:1241` processes
firmware reply descriptors. The SMID (System Message ID) is read from DMA
(firmware-controlled) and used as an array index with **no bounds check**:

```c
// line 1269-1270
smid = reply_desc->SMID;            // u_int16_t from DMA (0..65535)
cmd_mpt = sc->mpt_cmd_list[smid -1];  // NO bounds check!
scsi_io_req = (MRSAS_RAID_SCSI_IO_REQUEST *)cmd_mpt->io_request;
```

`smid` is `u_int16_t` (line 1244); `reply_desc->SMID` is also `u_int16_t`
(mrsas.h:361). The array `sc->mpt_cmd_list` has `max_fw_cmds` entries
(allocated at line 1023-1030). Two failure modes:

1. **`smid == 0`**: `smid - 1` = `-1` (int promotion) → `mpt_cmd_list[-1]`
   reads the pointer 8 bytes before the array → wild `cmd_mpt` → crash or
   corruption when dereferencing `cmd_mpt->io_request`.

2. **`smid > max_fw_cmds`**: `mpt_cmd_list[smid-1]` reads past the array
   → wild `cmd_mpt` → same.

The cascading dereferences are severe:
- `cmd_mpt->io_request` (line 1271)
- `cmd_mpt->ccb_ptr->ccb_h.target_id` (line 1279)
- `cmd_mpt->sync_cmd_idx` → `sc->mfi_cmd_list[idx]` (line 1295), where
  `mfi_cmd_list` has only `MRSAS_MAX_MFI_CMDS=32` entries (mrsas.h:1135)

Additionally, `max_fw_cmds` comes from the FW status register (line 1799)
with only a `-1` adjustment (line 1802) and **no minimum check** — if the
register reads 0, `max_fw_cmds` underflows to `0xFFFFFFFF` (uint), causing
massive over-allocation or other corruption.

**The bug is real in source.** A malicious firmware (or PCIe DMA injection
via a Thunderbolt/malicious-device vector) can set an arbitrary SMID,
causing OOB array access and wild pointer dereference in the kernel.

## Why it cannot reproduce on this guest

`mrsas` (LSI MegaRAID SAS, Thunderbolt series and up) **IS compiled into
the X86_64_GENERIC kernel** (confirmed: `nm /boot/kernel/kernel` shows
`mrsas_complete_cmd` at 0xffffffff804d54e0). However:

- The QEMU guest has **no LSI MegaRAID SAS controller** — `pciconf -l`
  shows only 440FX/PIIX3/PIIX4, VGA, virtio-net, virtio-blk.
- `mrsas_probe()` never matches a device → the driver never attaches →
  no interrupt handler is registered → `mrsas_complete_cmd` is never
  called. It is live-but-unreachable code on this guest.
- QEMU does not emulate LSI MegaRAID SAS (it supports `megasas-scsi` on
  some configs but not in this guest's QEMU command line, which uses
  virtio-blk).

This is **valid hard blocker: dead/unreachable at runtime on this guest**
(no hardware). The threat model is malicious firmware or a malicious
PCIe device on a real system with a MegaRAID SAS controller.

## Fix

`fix.diff` adds a bounds check: if `smid == 0 || smid > sc->max_fw_cmds`,
the entry is dropped (advances the reply index, marks the descriptor
consumed, continues). Validated by a successful single-fix kernel build
(`make -j6 nativekernel` rc=0).

## Impact

- **On this guest**: none (driver never attaches, no hardware).
- **On a real system**: OOB array access from a malicious firmware/PCIe
  device. The wild `cmd_mpt` pointer leads to arbitrary kernel memory
  dereference — likely a crash (DoS) from a buggy firmware, or a
  controlled corruption primitive from a malicious PCIe device. Triggered
  in interrupt context. This is a hardware/firmware-trust attack surface,
  not a local-user privesc.