DF-3843 — mrsas_sync_map_info: firmware ldCount drives an unbounded OOB write past the RAID-map DMA buffer

Where

• sys/dev/raid/mrsas/mrsas.c:3207 — num_lds = map->raidMap.ldCount; (full u32, firmware-authored)
• sys/dev/raid/mrsas/mrsas.c:3210 — size_sync_info = sizeof(MR_LD_TARGET_SYNC) * num_lds; — computed and never used
• sys/dev/raid/mrsas/mrsas.c:3213-3224 — write loop into raidmap_mem[(map_id-1)&1], a fixed map_sz = sizeof(MR_FW_RAID_MAP) + sizeof(MR_LD_SPAN_MAP)*(MAX_LOGICAL_DRIVES-1) = 172,200-byte bus_dmamem_alloc buffer (size set at mrsas.c:1645-1646)
• Validation gap: sys/dev/raid/mrsas/mrsas_fp.c:257-265 (MR_ValidateMapInfo) only checks totalSize == sizeof(MR_FW_RAID_MAP) - sizeof(MR_LD_SPAN_MAP) + sizeof(MR_LD_SPAN_MAP)*ldCount in u32 arithmetic — the firmware supplies both sides of that equation, so any ldCount passes.

Class

Linear kernel-heap overflow past a DMA allocation: length fully firmware-chosen (u32 count × 4 bytes), content = per 4-byte entry {targetId: FW u8, 0x00, seqNum: FW u16} (3 of 4 bytes attacker-chosen). The same loop also OOB-reads the source map via MR_LdRaidGet(i)/MR_GetLDTgtId(i) (mrsas_fp.c:174-182, unbounded ldSpanMap[i]).

Reachability

mrsas_sync_map_info is called from: 1. mrsas_setup_raidmap (mrsas.c:1680) at attach — after MR_ValidateMapInfo "passes", 2. mrsas_complete_mptmfi_passthru (mrsas.c:2965) on every RAID-map sync completion (AEN-driven), 3. mrsas_reset_ctrl (mrsas.c:2477) after OCR.

Threat actor: malicious/compromised controller firmware or a device that DMA-authors the map (the map buffer is filled by the card). No purely-local unprivileged trigger — this is the same gating as DF-1528 (mrsas_fp.c map reads), DF-1242/1243/1244.

Reproduce (arithmetic proof on the audit guest)

./build.sh   # cc -O2 -Wall -o /tmp/df3843_proof map_sync_overflow_proof.c
./run.sh     # runs the harness; struct definitions copied verbatim from mrsas.h

Expected decisive lines (see run.log):

map_sz (mrsas.c:1645)       = 172200  <- bus_dmamem_alloc size
capacity in sync entries    = 43050  (max ldCount before OOB)
Firmware supplies ldCount=65536, totalSize=0x9e028a8:
  MR_ValidateMapInfo: totalSize(0x9e028a8) == expected(0x9e028a8) -> PASSES
  => 89944 bytes written PAST the end of the DMA allocation

The kernel-side execution itself needs a MegaRAID SAS HBA (Thunderbolt/Invader/Fury); the audit QEMU guest has none (no LSI/Avago PCI device present, no /dev/mrsas* nodes) although the driver is compiled into X86_64_GENERIC (kldstat -v | grep mrsas → 80 pci/mrsas).

VERDICT — DF-3843

status: inconclusive (hardware-gated; source-certain) impact class: kernel memory corruption (linear OOB write, firmware-chosen length) confidence: certain (source + on-guest struct-math proof)

What was verified

1. Source trace (certain). mrsas_sync_map_info() reads the loop bound straight from the firmware-authored RAID map: - sys/dev/raid/mrsas/mrsas.c:3207 num_lds = map->raidMap.ldCount; - sys/dev/raid/mrsas/mrsas.c:3210 computes size_sync_info = sizeof(MR_LD_TARGET_SYNC) * num_lds and never uses it — the bound the author intended is dead code. - sys/dev/raid/mrsas/mrsas.c:3220-3224 writes one MR_LD_TARGET_SYNC (4 bytes) per iteration into target_map = sc->raidmap_mem[(sc->map_id - 1) & 1] (mrsas.c:3213), a buffer of exactly map_sz bytes (mrsas.c:1645-1646). - MR_ValidateMapInfo (sys/dev/raid/mrsas/mrsas_fp.c:257-265) does not bound ldCount; it only requires totalSize (another firmware field) to be arithmetically consistent with it in u32 math. Every ldCount has a passing totalSize.

2. Struct-math proof executed on the audit guest (map_sync_overflow_proof.c, run.log): - sizeof(MR_FW_RAID_MAP)=12936, sizeof(MR_LD_SPAN_MAP)=2528, sizeof(MR_FW_RAID_MAP_ALL)=172200 — matches the header's own comments (0x3288 / 0x9E0). - map_sz = 12936 + 2528*63 = 172200 bytes = 43,050 four-byte sync entries of capacity. - A map with ldCount=65536, totalSize=0x9e028a8 passes MR_ValidateMapInfo and makes the loop write 262,144 bytes — 89,944 bytes past the bus_dmamem_alloc region, with 22,486 fully-OOB entries of firmware-chosen {u8,u8=0,u16} payload. Larger counts (up to 2^32-1) overflow proportionally further; a malicious device picks length and content.

3. Guest execution of the kernel path: impossible on this host. The driver is compiled into the running kernel (kldstat -v → 80 pci/mrsas; sys/config/X86_64_GENERIC:123), but the guest has no LSI/Avago PCI device and no /dev/mrsas* node — the driver never attaches, so the firmware-facing trigger surface does not exist in the VM. Reproducing the corruption itself would require a MegaRAID HBA (or a hacked QEMU megasas model emitting a crafted map), which is outside this guest's capability. Hence inconclusive, not reproduced.

Exploit chain (if hardware/firmware control exists)

firmware DMA-authors RAID map with ldCount = K > 43050 (+consistent totalSize) → attach/AEN/OCR triggers mrsas_sync_map_info → linear overwrite of kernel memory adjacent to the 172,200-byte raidmap bus_dmamem_alloc, 3 controllable bytes per 4, length ≈ 4K−172200 → classic heap-metadata/vtable overwrite → code execution in kernel context. With K chosen near 43,050 the write stays small and surgical; with large K it is a destructive sledgehammer.

Why not false positive

The bound (size_sync_info) is computed and then ignored — the intent to bound exists in the code. Linux's megaraid_sas upstream equivalents allocate the sync buffer from ldCount (mr_update_load_balance_params/sync alloc paths) or clamp; this port dropped the clamp.

Fix validation

fix.diff adds an explicit ldCount > MAX_LOGICAL_DRIVES rejection in mrsas_sync_map_info (release cmd, return error) and a validation-time bound in MR_ValidateMapInfo so a bogus map never reaches fast-path code either. Not executable on this guest (no HBA) → fix_status = not_testable; the fix is structurally minimal and obviously removes the only path to the unbounded loop.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.