• File: sys/dev/raid/mpr/mpr_sas_lsi.c
• Lines: 885–897 (check), 908 (write)
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
• CWE: CWE-787 Out-of-bounds Write
• Confidence: likely

Summary

In mprsas_add_device, the PhyNum fallback path checks (id = config_page.PhyNum) > sassc->maxtargets using strictly-greater-than, allowing id == maxtargets to pass. Since sassc->targets is allocated with exactly maxtargets entries (indices 0..maxtargets-1, mpr_sas.c:761), targ = &sassc->targets[id] at line 908 writes one struct mprsas_target past the end of the heap allocation. A malicious HBA that reports a small MaxTargets in IOC facts and then sends a SAS device page0 with PhyNum == maxtargets triggers a heap OOB write.

Root cause

At mpr_sas_lsi.c:885-897:

id = MPR_MAP_BAD_ID;
if (sc->use_phynum != -1)
    id = mpr_mapping_get_tid(...);
if (id == MPR_MAP_BAD_ID) {
    if ((sc->use_phynum == 0) ||
        ((id = config_page.PhyNum) > sassc->maxtargets)) {   /* <-- BUG: should be >= */
        ...error...
    }
}

The comparison at line 890 is > (strictly greater), so PhyNum == maxtargets passes the check and id is set to maxtargets.

sassc->targets is kmalloc'd as sizeof(struct mprsas_target) * maxtargets at mpr_sas.c:761, so valid indices are 0..maxtargets-1.

At line 908: targ = &sassc->targets[id] with id == maxtargets is one past the end. Lines 925–957 then write ~20 fields into targ (devinfo, devname, encl_handle, encl_slot, handle, parent_handle, sasaddr, tid, linkrate, flags, etc.) — a full struct mprsas_target overwrite into adjacent heap.

config_page.PhyNum is U8 (0-255, mpi2_sas.h SAS device page0). maxtargets = MaxTargets + MaxVolumes (mpr_sas.c:760). If the HBA reports MaxTargets+MaxVolumes ≤ 255 (e.g., MaxTargets=128, MaxVolumes=8 → maxtargets=136), a PhyNum of 136 triggers the OOB.

use_phynum defaults to 1 (mpr.c:1678), so this fallback path is active by default.

Threat

Attacker is a malicious SAS HBA that controls both the IOC facts (MaxTargets, reported at attach time, mpr.c LSI facts read) and the SAS device page0 content (PhyNum, returned by mpr_config_get_sas_device_pg0).

The attacker sets MaxTargets+MaxVolumes to a value ≤ 255, triggers a topology-change event (device add) with a handle whose page0 has PhyNum == maxtargets and a SAS address that fails mapping (so the PhyNum fallback is taken).

Result: a heap OOB write of one full struct mprsas_target (~200 bytes) past the targets[] allocation. Impact: heap corruption of whatever follows targets[] in kernel memory — could overwrite function pointers, refcounts, or free-list metadata, potentially leading to code execution (I:H, A:H).

Physical access or firmware compromise required; attack complexity is higher because two firmware-controlled values must be coordinated and mapping must fail.

Exploit / PoC

Using a malicious SAS3 HBA (FPGA or custom QEMU device model):

1. During attach, report IOC facts with MaxTargets=128, MaxVolumes=8 → maxtargets=136, targets[] has 136 entries (indices 0-135).
2. Post a SAS_TOPOLOGY_CHANGE_LIST event with a PHY entry having PhyStatus=MPI2_EVENT_SAS_TOPO_RC_TARG_ADDED and an AttachedDevHandle (e.g., 0x0012).
3. When the driver calls mprsas_add_device(sc, 0x0012, ...), respond to the mpr_config_get_sas_device_pg0 request with a page0 whose SASAddress is 0 (or any address that mpr_mapping_get_tid rejects → returns MPR_MAP_BAD_ID), and PhyNum=136.
4. The check 136 > 136 is false, so id=136. Line 908: targ = &sassc->targets[136] — one past the 136-element array.
5. Lines 925-957 write ~20 fields into the out-of-bounds slot, corrupting adjacent heap.

Expected result: heap corruption; with KASAN, an OOB-write report; without KASAN, potential panic on subsequent use of corrupted data or exploitable heap corruption.

Recommended fix

Change the comparison from strictly-greater-than to greater-than-or-equal:

--- a/sys/dev/raid/mpr/mpr_sas_lsi.c
+++ b/sys/dev/raid/mpr/mpr_sas_lsi.c
@@ -887,7 +887,7 @@
    if (id == MPR_MAP_BAD_ID) {
        if ((sc->use_phynum == 0) ||
-           ((id = config_page.PhyNum) > sassc->maxtargets)) {
+           ((id = config_page.PhyNum) >= sassc->maxtargets)) {
            mpr_dprint(sc, MPR_INFO, "failure at %s:%d/%s()! "
                "Could not get ID for device with handle 0x%04x\n",
                __FILE__, __LINE__, __func__, handle);

Related findings

• DF-1473/1474 (sibling): event handler OOB family in same file.
• DF-1282/1283 (sibling, mpr_mapping): DPM DeviceIndex OOB.