⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-1244

mrsas_get_ld_list indexes ld_ids with unchecked firmware targetId (OOB byte write)

Summary

mrsas_get_ld_list at mrsas.c:3385-3386: ids=ldList[ld_index].targetId (u8 0-255 from firmware), sc->ld_ids[ids]=targetId. ld_ids is MRSAS_MAX_LD=64 bytes (mrsas.h:2418). targetId>=64 writes 1 byte past into ev_tq ptr/reset_flags/load_balance_info. Guard at :3380 bounds ldCount<=64 but not targetId value. CAM max_target=63, so host never produces >=64. Triggered at attach and re-triggered on LD_CREATED/OFFLINE/DELETED/CFG_CLEARED AEN. Malicious/buggy HBA. Fix: check ids<MRSAS_MAX_LD.

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-1244 · 8 files
FileTypeDescriptionSize
VERDICT.md verdict source trace, mechanism, impact ceiling, fix rationale 2.5 KB ↓ raw
fix.diff suggested-fix git-apply-able bounds check on targetId before ld_ids[ids] 744 B view raw
fix_build.log build-log mrsas.ko build with fix applied (88328 bytes, RC=0) 1023 B view raw
build.sh build-log repro: apply-check + note 600 B view raw
run.sh run-log no runtime trigger (no HW) 550 B view raw
env.txt environment uname, cc version, module state 359 B view raw
../fix_build_combined.log build-log Combined 41-finding kernel build (rc=0, -Werror clean) 5.6 MB ↓ download
../fix_build_summary.txt build-summary Summary of the combined 41-finding kernel build 826 B view raw
VERDICT.md verdict source trace, mechanism, impact ceiling, fix rationale
↓ download raw

DF-1244 — mrsas_get_ld_list indexes ld_ids with unchecked firmware targetId (OOB byte write)

Verdict

SOURCE-CONFIRMED (real bug), INCONCLUSIVE at runtime — the vulnerable code is compiled into the running GENERIC kernel (device mrsas), but the required LSI MegaRAID SAS controller is absent from the QEMU guest, so the code path is dormant and cannot be exercised. Fix authored and compile-validated.

Mechanism (source trace)

mrsas_get_ld_list() issues the MR_DCMD_LD_GET_LIST DCMD to the firmware and walks the returned MR_LD_LIST:

Call sites: mrsas_attach (mrsas.c:1734) and mrsas_aen_handler on MR_EVT_LD_CREATED/LD_DELETED (mrsas.c:3570,3575,3596). Both require a mrsas device to be attached.

Why not reproduced at runtime

  • Guest PCI inventory: only virtio devices (vtblk0, vtnet0). No MegaRAID SAS controller ⇒ mrsas_pci_probe never matches ⇒ mrsas_attach never runs ⇒ mrsas_get_ld_list is dead code on this guest.
  • The trigger is a firmware-supplied bad targetId (malicious/buggy controller or VFIO-passthrough device), not unprivileged-user input.
  • This is a driver-robustness / defense-in-depth hardening gap: a misbehaving or emulated controller can OOB-write into the softc. The CAM layer caps max_target = MRSAS_MAX_LD-1 = 63 for outgoing queries (mrsas_cam.c:323), but that does not constrain the incoming firmware DCMD response that populates ld_ids.

Fix (fix.diff, compile-validated)

Validate ids < MRSAS_MAX_LD before indexing; log and skip out-of-range entries. The patched mrsas.c builds cleanly into mrsas.ko (88328 bytes) with gcc 8.3, -Werror.

Realistic impact ceiling

Kernel heap/softc corruption from a malicious or buggy MegaRAID controller. On this guest: not reachable (no HW). Classify as Medium-severity hardening fix.

Fix verification

not_testable

compile validated

module/object build rc=0
↓ fix.diffn/a

Confirmed kernel references

—

Detail

Exploit chain

none

Evidence (decisive lines)

—

Verdict

Source-confirmed. mrsas_get_ld_list ld_ids[targetId] no bounds vs [64]. mrsas in GENERIC, no MegaRAID HW.