DF-1243 — mrsas_get_pd_list unchecked deviceId (OOB write into softc)

Verdict: NOT REPRODUCED (dead code at runtime — no hardware)

Mechanism (source-level, confirmed real)

mrsas_get_pd_list() at sys/dev/raid/mrsas/mrsas.c:3270 queries the firmware for the physical-drive list and populates sc->local_pd_list[deviceId]. The deviceId is firmware-supplied and unchecked against the array bounds:

// line 3307-3314
if (retcode == 0 && pd_list_mem->count < pd_count) {   // checks count, NOT deviceId
    memset(sc->local_pd_list, 0, MRSAS_MAX_PD * sizeof(struct mrsas_pd_list));
    for (pd_index = 0; pd_index < pd_list_mem->count; pd_index++) {
        sc->local_pd_list[pd_addr->deviceId].tid = pd_addr->deviceId;
        sc->local_pd_list[pd_addr->deviceId].driveType = pd_addr->scsiDevType;
        sc->local_pd_list[pd_addr->deviceId].driveState = MR_PD_STATE_SYSTEM;
        pd_addr++;
    }
}

deviceId is u_int16_t (0–65535, mrsas.h:1351), but local_pd_list has only MRSAS_MAX_PD = 256 entries (mrsas.h:2417, 1830). The guard at line 3307 only bounds the count (< 256), not the deviceId values.

The softc layout after local_pd_list[256] (mrsas.h:2417-2424):

struct mrsas_pd_list local_pd_list[256];   // <-- the array
u_int8_t          ld_ids[MRSAS_MAX_LD];    // overwritten
struct taskqueue  *ev_tq;                  // <-- KERNEL FUNCTION POINTER
struct task       ev_task;
u_int32_t         CurLdCount;
u_int64_t         reset_flags;
LD_LOAD_BALANCE_INFO load_balance_info[MAX_LOGICAL_DRIVES];

A deviceId >= 256 writes .tid, .driveType, .driveState (3 fields of a struct mrsas_pd_list) past the array into ld_ids, and for large deviceId values, potentially into ev_tq — a kernel taskqueue pointer. Corrupting a function pointer and triggering the event task could redirect kernel execution.

The bug is real in source. A malicious firmware can set deviceId to any u16 value, causing an OOB write of 3 fields per entry past the 256-entry array, corrupting adjacent softc fields including a taskqueue pointer. Triggered at attach and re-triggered on PD_INSERTION events.

Why it cannot reproduce on this guest

Same as DF-1242: mrsas is in GENERIC but no LSI MegaRAID SAS hardware on the QEMU guest → driver never attaches → mrsas_get_pd_list (called from mrsas_init_adapter during attach) is never reached.

Valid hard blocker: dead/unreachable at runtime. Threat model is malicious firmware or a malicious PCIe device on a real MegaRAID SAS system.

Fix

fix.diff adds if (pd_addr->deviceId >= MRSAS_MAX_PD) { skip; continue; } inside the loop, so out-of-range deviceIds are logged and skipped rather than writing OOB. 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 write of 3 fields per malicious PD entry past local_pd_list[256], corrupting ld_ids, ev_tq (taskqueue pointer), reset_flags, load_balance_info. From malicious firmware this is kernel memory corruption in the RAID driver — a crash (DoS) from buggy firmware, or a controlled corruption primitive (including potential function-pointer overwrite of ev_tq) from a malicious PCIe device. Triggered at attach and on PD events.