# 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.