DF-4559 VERDICT — reproduced (harness), High, OOB heap write in mps IR volume registration

Bottom line

sassc->targets[] is allocated with sc->facts->MaxTargets entries (sys/dev/raid/mps/mps_sas.c:696-697) while the mapping layer legitimately hands out target IDs up to sc->max_devices - 1 = facts->MaxTargets + facts->MaxVolumes - 1 (sys/dev/raid/mps/mps_mapping.c:1733-1734, :232-234). In HIGH IR-volume-mapping mode every RAID volume ID indexes past the end of the array. Both RAID-volume registration sinks live in the file under audit and write there: mpssas_volume_add() (sys/dev/raid/mps/mps_sas_lsi.c:847-853: tid, fw u16 handle, fw-controlled u64 devname = wwid, TAILQ_INIT/SLIST_INIT NULL pointer pairs) and the IR CONFIG CHANGE REMOVED branch (sys/dev/raid/mps/mps_sas_lsi.c:310-316: six zeroing writes), plus the OOB targetid = targ - sassc->targets computation fed into CAM (sys/dev/raid/mps/mps_sas.c:285 via mpssas_rescan_target from mps_sas_lsi.c:317/:855).

Why it reproduces (evidence)

Guard-page harness on the DragonFly 6.5-DEVELOPMENT guest (run.log, run.2.log — two consecutive runs, identical):

• voladd-HIGH: the write sequence of mps_sas_lsi.c:848-853 at id = max_devices - max_volumes = MaxTargets SIGSEGVs on the guard page — the write begins at byte n*sizeof(mpssas_target) of an n*sizeof(mpssas_target)-byte allocation: unambiguously past the end.
• removed-HIGH: zeroing writes of :311-316 at id = max_devices-1 fault 1600 bytes past the end.
• voladd-LOW control: clean — proves the trigger is exactly the ID-range mismatch, not the write sequence.
• Canary: 416 bytes corrupted past a 51200-byte allocation ([+51200..+52679]); readback of devname at +51208 returns the fw-supplied u64 verbatim — the controlled-write primitive is real.

Threat model / reachability

• The gate is IOC page 8 IRVolumeMappingFlags selecting HIGH volume mapping plus any IR volume event (volume created / comes online (mps_sas_lsi.c:288/:406), or removed (:296-317)). That is a supported, operator-selectable configuration on LSI IR firmware — the corruption fires during normal discovery on such boxes, no malicious input needed.
• In the malicious-firmware threat model (same one DF-1696/1697 use), the fw fully controls the ID (mapping table) and the 8-byte wwid payload.
• What stops short of uid=0: the write content is constrained (fixed offsets inside struct mpssas_target, value set = {bounded id, fw u16 handle, fw u64 wwid, NULLs, zeros}) and the overflow distance is k*sizeof(mpssas_target) for k < MaxVolumes — adjacent-heap corruption of whatever follows the targets allocation, panic-grade in practice. The guest has no mps HBA, so an end-to-end in-driver escalation chain cannot be demonstrated on this hardware; per the DF-4363/DF-4013 precedent the primitive is proven by the byte-exact harness.

Root cause (path:line)

• sys/dev/raid/mps/mps_sas.c:696-697 — allocation sized sc->facts->MaxTargets.
• sys/dev/raid/mps/mps_mapping.c:1733-1734 — ID space is MaxTargets + MaxVolumes (sc->max_devices).
• sys/dev/raid/mps/mps_mapping.c:232-234 — HIGH volume mapping puts volume IDs at the top of that space.
• sys/dev/raid/mps/mps_sas_lsi.c:847-853 and :310-317 — the OOB sinks.
• sys/dev/raid/mps/mps_sas.c:181 — find_target_by_handle scanning only [0, MaxTargets) corroborates the divergence (volumes are invisible to the "already added" check at mps_sas_lsi.c:400).

Fix validation

fix.diff sizes sassc->targets with sassc->maxtargets = facts->MaxTargets + facts->MaxVolumes and uses it for the by-handle scan. Harness arm voladd-HIGH-FIXED re-runs the identical write sequence against the fixed sizing: clean exit, zero canary clobber — the previously-observed OOB write is gone (baseline vs patched in run.log).

Notes

• The informational harness arm also documents the max_devices u16 truncation corner (MaxTargets=65535/MaxVolumes=255 → max_devices=254 → start_idx wraps to 0xFFFFFFFF at mps_sas_lsi.c:901): malicious-fw only, wild mapping_table[0xffffffff] read at shutdown; folded into this pack's notes rather than filed separately (absurd facts values).
• Guest dirtied only with /root harness binaries; guest reset (with-src) performed after the run.

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.