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:

// 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.