• File: sys/dev/raid/mpr/mpr_sas_lsi.c
• Lines: 216, 294, 729
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L
• CWE: CWE-125 Out-of-bounds Read
• Confidence: certain

Summary

In mprsas_fw_work, three event handlers iterate over variable-length arrays (PHY[], ConfigElement[], PortEntry[]) using a firmware-supplied count field (NumEntries / NumElements) read from inside the event data buffer as the loop bound. The count is never validated against the actual allocation size of fw_event->event_data (which is EventDataLength*4 bytes). A malicious HBA that sets a small EventDataLength but a large NumEntries/NumElements causes the loop to read hundreds of bytes past the heap allocation into adjacent kernel heap.

Root cause

Three independent loops, identical pattern:

1. SAS topology at mpr_sas_lsi.c:216: for (i = 0; i < data->NumEntries; i++) { phy = &data->PHY[i]; ... } where data is MPI2_EVENT_DATA_SAS_TOPOLOGY_CHANGE_LIST * cast from fw_event->event_data. The struct declares PHY[MPI2_EVENT_SAS_TOPO_PHY_COUNT] (= PHY[1], mpi2_ioc.h:1067) with a comment "Host code should leave this set to one and check NumEntries at runtime" — but the runtime check against the buffer is missing. NumEntries is U8 (max 255); each PHY entry is 4 bytes; the header is 12 bytes; so valid entries need (12 + NumEntries*4) bytes. If the allocation (EventDataLength*4) is smaller, data->PHY[i] for large i reads OOB.

2. IR config change at line 294: for (i = 0; i < event_data->NumElements; i++, element++) where element starts at &event_data->ConfigElement[0] (mpi2_ioc.h:909, ConfigElement[1]). Each Mpi2EventIrConfigElement_t is 8 bytes; header is 8 bytes. Before the loop, element->VolDevHandle is already dereferenced at line 291.

3. PCIe topology at line 729: for (i = 0; i < data->NumEntries; i++) { port_entry = &data->PortEntry[i]; ... } with PortEntry[1] (mpi2_ioc.h:1361), each entry 4 bytes.

In all three cases, the allocation was sized by EventDataLength (line 149) but the loop walks past it based on the in-buffer count.

Concrete example: firmware sends EventDataLength=7 (28-byte alloc for topology: 12-byte header + 16 bytes = room for 4 PHY entries) but sets NumEntries=255 → loop reads data->PHY[0..254] = 12+255*4 = 1032 bytes from a 28-byte allocation, reading ~1KB of adjacent kernel heap.

Threat

Attacker is a malicious/compromised SAS HBA that crafts an event notification with a mismatched EventDataLength (small allocation) and NumEntries/NumElements (large loop bound). The OOB-read values (AttachedDevHandle, PhyStatus, LinkRate, VolDevHandle, PhysDiskDevHandle, ReasonCode) are then passed to mprsas_add_device, mprsas_prepare_remove, mprsas_volume_add, and RAID-action request construction — driving further firmware commands and target-table mutations with attacker-influenced (heap-garbage) data.

Primary impact: kernel heap OOB read leaking adjacent allocation contents (C:L), potential panic if OOB data causes a bad dereference in downstream code (A:L).

Same threat model as DF-1282/DF-1283/DF-1370 (malicious PCIe HBA). Requires physical access or firmware compromise.

Exploit / PoC

Using a malicious SAS3 HBA (FPGA card or custom QEMU device model, PCI ID 1000:0097):

1. Wait for the driver to register for events (mprsas_evt_handler registered via mpr_register_events at mpr_sas.c:731).
2. Post an event reply with Event=0x0016 (MPI2_EVENT_SAS_TOPOLOGY_CHANGE_LIST), EventDataLength=7 (28 bytes — room for 4 PHY entries), and in the event data set NumEntries=255 at offset 0x08. Fill PHY[0..3] with valid-looking entries (PhyStatus with MPI2_EVENT_SAS_TOPO_RC_TARG_ADDED bit set, arbitrary AttachedDevHandle).
3. The handler allocates 28 bytes, copies 28 bytes, then loops 255 times reading data->PHY[4..254] — 1004 bytes past the allocation. Each iteration reads a 4-byte AttachedDevHandle and 1-byte PhyStatus from adjacent kernel heap.

Expected result: KASAN OOB-read report, or silent heap over-read driving spurious device-add operations with garbage handles.

Recommended fix

Store the allocation size in struct mpr_fw_event_work (e.g. add a size_t alloc_sz field set at line 149), then clamp the count fields in all three loops:

/* SAS_TOPOLOGY_CHANGE_LIST (line 216) */
uint8_t max_phy = (fw_event->alloc_sz >= 12) ?
    (fw_event->alloc_sz - 12) / sizeof(MPI2_EVENT_SAS_TOPO_PHY_ENTRY) : 0;
if (data->NumEntries > max_phy)
    data->NumEntries = max_phy;

/* IR_CONFIG_CHANGE_LIST (line 294) */
uint8_t max_elt = (fw_event->alloc_sz >= 8) ?
    (fw_event->alloc_sz - 8) / sizeof(Mpi2EventIrConfigElement_t) : 0;
if (event_data->NumElements > max_elt)
    event_data->NumElements = max_elt;

/* PCIe_TOPOLOGY_CHANGE_LIST (line 729) */
uint8_t max_port = (fw_event->alloc_sz >= 12) ?
    (fw_event->alloc_sz - 12) / sizeof(MPI2_EVENT_DATA_PCIE_TOPO_PORT_ENTRY) : 0;
if (data->NumEntries > max_port)
    data->NumEntries = max_port;

(Or pass EventDataLength through fw_event and compute the bounds inline.)

Related findings

• DF-1473 (sibling): u16 truncation of EventDataLength*4 in same file.
• DF-1475 (sibling): off-by-one PhyNum target-ID fallback in same file.
• DF-1282/1283 (sibling, mpr_mapping): DPM DeviceIndex OOB.
• DF-1370 (twin, mps driver): EventDataLength OOB read of reply DMA pool.