• File: sys/dev/raid/mpr/mpr_sas_lsi.c
• Lines: 136, 148, 149, 156
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
• CWE: CWE-190 Integer Overflow or Wraparound
• Confidence: certain

Summary

mprsas_evt_handler computes the event-data copy size as u16 sz = le16toh(event->EventDataLength) * 4. EventDataLength is a U16 firmware-controlled field from the DMA reply; multiplying by 4 yields up to 262140, which silently truncates to 16 bits. For EventDataLength=0x4000/0x8000/0xC000, sz wraps to 0 → kmalloc(0) returns ZERO_LENGTH_PTR ((void*)-8), and every subsequent structure field access (data->NumEntries, data->ReasonCode, etc.) dereferences near-NULL → guaranteed kernel panic. For EventDataLength=0x4001 etc., sz wraps to a tiny value → undersized heap allocation → OOB heap read when parsing any event data structure whose fields extend past the allocated region.

Root cause

At mpr_sas_lsi.c:136, sz is declared u16. At line 148: sz = le16toh(event->EventDataLength) * 4;. The multiplication is performed in int arithmetic (C integer promotion), producing the correct product up to 262140, but the assignment to u16 sz truncates to the low 16 bits.

For EventDataLength ≥ 0x4000 (16384), the true byte size is ≥ 65536, but sz becomes (true_size & 0xFFFF).

Manifestation A (panic): EventDataLength=0x4000 → sz=0 → kmalloc(0, M_MPR, M_ZERO|M_NOWAIT) returns ZERO_LENGTH_PTR per kern_slaballoc.c:888-890 → non-NULL so the check at line 150 passes → bcopy copies 0 bytes → fw_event->event_data = (void*)-8. When mprsas_fw_work processes the event, e.g. line 254 data = (...)fw_event->event_data then line 256 data->ReasonCode reads from address -8+1 = 0xFFFFFFFFFFFFFFF9 (x86-64 kernel, unmapped) → page fault → panic.

Manifestation B (OOB read): EventDataLength=0x4001 → sz=4 → kmalloc(4) → only 4 bytes allocated and copied → accessing data->NumEntries (offset 0x08 in SAS_TOPOLOGY_CHANGE_LIST, offset 0x00 NumElements in IR_CONFIG_CHANGE_LIST at line 285-286 reading Flags at offset 0x04) reads past the 4-byte allocation into adjacent kernel heap.

Additionally, even without truncation (EventDataLength ≤ 0x3FFF), the bcopy at line 156 reads sz bytes from event->EventData in the reply DMA frame without bounding sz against replyframesz (typically ~96 bytes), so EventDataLength > ~24 causes an OOB read of the reply DMA pool — same class as DF-1370 in the sibling mps driver.

Threat

Attacker is a malicious or compromised SAS HBA (PCIe device — e.g., a counterfeit card, Thunderbolt/ExpressCard attachment, or firmware-update-compromised HBA) that writes a crafted EventDataLength into the DMA event reply buffer. The event reply is consumed by mpr_intr_locked → mpr_dispatch_event (mpr.c:2403,2452) → mprsas_evt_handler (interrupt context).

For manifestation A, a single event with EventDataLength=0x4000 causes an immediate kernel panic — unambiguous system crash (A:H).

For manifestation B, an undersized allocation leads to OOB heap reads that can leak adjacent kernel heap data (pointers, potentially defeating KASLR) or corrupt internal driver state by acting on garbage values (C:L, A:L).

Physical access to a PCIe slot or prior firmware compromise is required; no userland syscall triggers this path.

Exploit / PoC

Reproduce with a malicious PCIe device (FPGA-based card or custom QEMU device model for the LSI SAS3 controller PCI ID 1000:0097) that sends an MPI2_EVENT_NOTIFICATION_REPLY via the reply DMA post queue with EventDataLength set to 0x4000 (dwords).

1. Boot DragonFlyBSD with the mpr driver loaded and an emulated/malicious SAS3 HBA present.
2. Have the device post an Address Reply descriptor (SMID=0) pointing to a reply frame whose Event field is MPI2_EVENT_SAS_TOPOLOGY_CHANGE_LIST (0x0016) and EventDataLength is 0x4000.
3. mpr_intr_locked reads the reply, calls mpr_dispatch_event → mprsas_evt_handler. sz = 0x4000*4 = 0x10000, truncated to u16 = 0. kmalloc(0) returns ZERO_LENGTH_PTR.
4. The event is queued; the taskqueue thread calls mprsas_fw_work; the SAS_TOPOLOGY_CHANGE_LIST case casts fw_event->event_data to a struct pointer and dereferences offset 0x00 (EnclosureHandle) at address 0xFFFFFFFFFFFFFFF8 → fatal pagefault/crash.

Expected result: immediate kernel panic (panic message: virtual page fault in kernel mode).

For the OOB variant, set EventDataLength=0x4001 (sz wraps to 4) and embed NumEntries=255 in the copied 4 bytes via the first dword — the loop at line 216 reads 255 PHY entries past the 4-byte allocation, leaking ~1KB of adjacent kernel heap.

Recommended fix

Declare sz as uint32_t and clamp it to the maximum sane event data size bounded by the reply frame.

--- a/sys/dev/raid/mpr/mpr_sas_lsi.c
+++ b/sys/dev/raid/mpr/mpr_sas_lsi.c
@@ -133,7 +133,7 @@
     MPI2_EVENT_NOTIFICATION_REPLY *event)
 {
    struct mpr_fw_event_work *fw_event;
-   u16 sz;
+   uint32_t sz;

    mpr_dprint(sc, MPR_TRACE, "%s\n", __func__);
    MPR_DPRINT_EVENT(sc, sas, event);
@@ -145,8 +145,14 @@
        kprintf("%s: allocate failed for fw_event\n", __func__);
        return;
    }
-   sz = le16toh(event->EventDataLength) * 4;
-   fw_event->event_data = kmalloc(sz, M_MPR, M_ZERO|M_NOWAIT);
+   sz = (uint32_t)le16toh(event->EventDataLength) * 4;
+   /*
+    * Clamp to the reply frame size to avoid OOB reads of the DMA
+    * reply pool and reject zero-length / impossibly large values.
+    */
+   if (sz == 0 || sz > sc->replyframesz)
+       sz = sc->replyframesz;
+   fw_event->event_data = kmalloc(sz, M_MPR, M_ZERO|M_NOWAIT);
    if (!fw_event->event_data) {
        kprintf("%s: allocate failed for event_data\n", __func__);
        kfree(fw_event, M_MPR);

Related findings

• DF-1370 (twin, mps driver): EventDataLength OOB read of reply DMA pool.
• DF-1474 (sibling): unbounded NumEntries loop in same file.
• DF-1475 (sibling): off-by-one PhyNum target-ID fallback in same file.