Summary

mpssas_evt_handler stores the event-data copy length in a u16 sz (line 128) and computes sz = le16toh(event->EventDataLength) * 4 (line 140). EventDataLength is firmware-controlled U16 (up to 65535); the multiply yields up to 262140 in int but is silently truncated by the u16 lvalue.

• For EventDataLength >= 0x4000 sz wraps to 0, kmalloc(0) returns ZERO_LENGTH_PTR ((void*)-8) per kern_slaballoc.c:888-890, the non-NULL check at :142 passes, bcopy copies 0 bytes, and the very first field dereference inside mpssas_fw_work (e.g. data->NumEntries at :208, event_data->NumElements at :283, logEntry->LogEntryQualifier at :515) reads near-NULL → fatal page fault.
• For EventDataLength = 0x4001..0x7FFF, sz wraps to 4..65532 → undersized heap alloc → all struct field accesses at offsets past sz are heap OOB reads.
• Additionally, even without truncation (EventDataLength <= 0x3FFF), the bcopy at :148 reads sz bytes from event->EventData inside the DMA reply frame without bounding sz against sc->facts->ReplyFrameSize*4 (mps.c:718); for EventDataLength > ~7 dwords the bcopy over-reads the reply DMA pool.

This is the exact mps-driver twin of DF-1473 in mpr_sas_lsi.c.

Root cause

mps_sas_lsi.c:128 u16 sz; then mps_sas_lsi.c:140 sz = le16toh(event->EventDataLength) * 4;. C integer promotion computes the product as int (up to 262140) but assignment to u16 truncates to the low 16 bits.

mps_sas_lsi.c:141 fw_event->event_data = kmalloc(sz, M_MPT2, M_ZERO|M_INTWAIT); — M_INTWAIT does NOT save us here because kern_slaballoc.c:888 short-circuits size==0 to ZERO_LENGTH_PTR before any wait/retry logic.

mps_sas_lsi.c:148 bcopy(event->EventData, fw_event->event_data, sz); propagates the truncation: a wrapped-small sz still copies a small slice but the source event->EventData lives in a single DMA reply frame bounded by sc->facts->ReplyFrameSize*4 (typically 16-32 bytes, set up at mps.c:718), so any EventDataLength > ~7 dwords reads adjacent reply frames or past the pool.

mps_sas_lsi.c:142 if (!fw_event->event_data) does not catch ZERO_LENGTH_PTR because (void*)-8 is non-NULL.

The malformed event reaches mpssas_fw_work via TAILQ at :166-167 and is processed by the taskqueue thread under mps_lock; the first deref in the matching case panics or OOB-reads.

Threat model

Attacker is a malicious or compromised SAS2 HBA (LSI Fusion-MPT 9207/9211 family; PCI IDs 1000:0097 etc.) reachable via PCIe — counterfeit card, Thunderbolt/ExpressCard hot-plug, or firmware-update compromise.

The malicious device posts an Address Reply descriptor with SMID=0 pointing at a crafted MPI2_EVENT_NOTIFICATION_REPLY whose Event field is any handled value (e.g. MPI2_EVENT_SAS_TOPOLOGY_CHANGE_LIST=0x001C) and EventDataLength is 0x4000 (panic) or 0x4001..0x7FFF (heap OOB).

mps_intr_locked (mps.c:1477) → mps_dispatch_event (mps.c:1617) → mpssas_evt_handler (this file).

Impact:

• A (panic): single malicious event is an unconditional kernel panic — A:H
• B (OOB): struct field reads at fixed offsets (0x00, 0x04, 0x08, 0x0C, 0x14, …) read adjacent kernel heap, leaking pointers (KASLR defeat) and driving downstream mps_mapping_* calls with garbage values (C:L)

No userland syscall triggers this; physical PCIe access or firmware compromise is required, matching the established threat model of DF-1370/ DF-1473.

Note: mps_sas_lsi.c uses M_INTWAIT (vs M_NOWAIT in mpr twin) but this only affects memory-pressure behavior, not the size==0 short-circuit, so the panic is just as reliable.

PoC

Reproduce with a malicious PCIe device: an FPGA SAS2 card or a custom QEMU device model implementing the LSI SAS2008 register interface (PCI ID 1000:0072).

On the DragonFlyBSD guest:

1. ensure the mps driver attaches and registers events (default behavior — mps_sas.c:678 calls mps_register_events with mpssas_evt_handler)
2. wait for the host to send MPI2_EVENT_REQUEST enabling event notification
3. post an Address Reply descriptor (SMID=0) whose ReplyFrameAddress points at a 16-byte reply frame containing: - EventDataLength=0x4000 (le16) - MsgLength=0x18 - Function=0x51 (EventNotificationReply) - Event=0x001C (SAS_TOPOLOGY_CHANGE_LIST) - EventContext=0
4. the driver calls mpssas_evt_handler; sz = 0x4000*4 = 0x10000 truncated to u16 = 0; kmalloc(0) returns ZERO_LENGTH_PTR; bcopy copies 0 bytes; fw_event is queued
5. mpssas_firmware_event_work dequeues, calls mpssas_fw_work; case MPI2_EVENT_SAS_TOPOLOGY_CHANGE_LIST at :197 casts event_data (== (void*)-8) to MPI2_EVENT_DATA_SAS_TOPOLOGY_CHANGE_LIST *data; line :206 calls mps_mapping_topology_change_event(sc, fw_event->event_data) which dereferences offset 0x00 → load from 0xFFFFFFFFFFFFFFF8 on x86-64 → page fault in kernel mode → panic

For the OOB variant, set EventDataLength=0x4001 (sz wraps to 4) and embed NumEntries=255 at offset 0x08 inside the 4 copied bytes; the loop at :208 then reads data->PHY[0..254] (offsets 0x0C..0x40C) from a 4-byte allocation → ~1 KB heap OOB read.

Success criterion: guest dmesg shows Fatal trap 12: page fault while in kernel mode and mpssas_fw_work in the backtrace (panic variant); KASAN-style splat or spurious mps_mapping calls driven by garbage handles (OOB variant).

findings/poc/DF-1696/: PoC scaffolding is a Python script using qemu.qmp to drive a tiny custom PCI device that issues the malicious reply descriptor — drop with build.sh (just qemu-system-x86_64 ...), run.sh, and a captured panic.txt.

Recommended fix

Declare sz as uint32_t (matching the firmware field's U16 * 4 max of 262140) and bound it against the actual reply frame size so neither kmalloc nor bcopy can overflow.

--- a/sys/dev/raid/mps/mps_sas_lsi.c
+++ b/sys/dev/raid/mps/mps_sas_lsi.c
@@ -125,7 +125,7 @@ void
 mpssas_evt_handler(struct mps_softc *sc, uintptr_t data,
     MPI2_EVENT_NOTIFICATION_REPLY *event)
 {
    struct mps_fw_event_work *fw_event;
-   u16 sz;
+   uint32_t sz, maxsz;

    mps_dprint(sc, MPS_TRACE, "%s\n", __func__);
    mps_print_evt_sas(sc, event);
@@ -137,8 +137,20 @@ mpssas_evt_handler(struct mps_softc *sc, uintptr_t data,
        return;
    }
    sz = le16toh(event->EventDataLength) * 4;
+   /*
+    * Clamp the copy length to the usable bytes of the reply frame so
+    * that bcopy() cannot over-read the DMA reply pool and sz cannot
+    * wrap when stored.  ReplyFrameSize is in dwords.
+    */
+   maxsz = (uint32_t)sc->facts->ReplyFrameSize * 4;
+   if (maxsz > offsetof(MPI2_EVENT_NOTIFICATION_REPLY, EventData))
+       maxsz -= offsetof(MPI2_EVENT_NOTIFICATION_REPLY, EventData);
+   else
+       maxsz = 0;
+   if (sz > maxsz)
+       sz = maxsz;
+   if (sz == 0)
+       sz = 4; /* at least one dword so downstream derefs are valid */
    fw_event->event_data = kmalloc(sz, M_MPT2, M_ZERO|M_INTWAIT);
-   if (!fw_event->event_data) {
+   if (fw_event->event_data == NULL) {
        kprintf("%s: allocate failed for event_data\n", __func__);
        kfree(fw_event, M_MPT2);
        return;

(A cleaner long-term fix also adds a size_t alloc_sz field to struct mps_fw_event_work so the loops in mpssas_fw_work can clamp NumEntries/NumElements at iteration time — see DF-1697.)

Related findings

• DF-1473 (mpr_sas_lsi.c — equivalent twin bug)
• DF-1370 (mps_user.c — same driver family)
• DF-1697 (sibling in same file: SAS topology + IR config change loop OOB)