DF-4363 — mps_config_get_man_pg10: firmware-controlled DMA heap overflow

sys/dev/raid/mps/mps_config.c — the ONLY getter in the file that allocates a fixed-size page buffer while the DMA length comes from the firmware config page header.

• mps_config.c:249 cm->cm_length = le16toh(mpi_reply->Header.PageLength) * 4; (PageLength is U8 → up to 255 → cm_length up to 1020 bytes)
• mps_config.c:254 page = kmalloc(MPS_MAN_PAGE10_SIZE, ...) with MPS_MAN_PAGE10_SIZE 0x5C = 92 bytes (mpsvar.h:105)
• mps_config.c:260 cm->cm_data = page; → mps_request_polled → mps.c:2099-2101 bus_dmamap_load(..., cm->cm_data, cm->cm_length, ...) → mps_data_cb SGEs cover cm_length bytes; the IOC DMAs the whole Manufacturing Page 10 past the end of the 92-byte heap object.

Every sibling allocation in this file and every one in the newer sys/dev/raid/mpr/mpr_config.c uses kmalloc(cm->cm_length, ...) — this is the one divergent site (mp r twin: mpr_config.c:145,277,450,588,724,861,998, 1130,1262,1394,1552).

Reachable at attach/discovery on WarpDrive HBAs (mps_pci.c:143 SSS6200 → MPS_FLAGS_WD_AVAILABLE; mps_sas.c:3320 → mps_wd_config_pages → mps_config.c:368). Same threat model as DF-1556/DF-1557: a buggy or malicious IOC firmware (or a device posing as one, e.g. hotplug/Thunderbolt) corrupts kernel heap memory with fully firmware-chosen bytes, up to 928 bytes past a 92-byte M_MPT2 allocation.

Reproduce (on the DragonFly guest, unprivileged)

cc -O2 -Wall -Wextra -o harness harness.c
./harness 24     # minimal overflow: 96-byte DMA into 92-byte kmalloc -> SIGSEGV
./harness 23     # boundary: 92 bytes exactly -> clean pass
./harness 255    # max: 1020-byte DMA -> 928 bytes past the allocation -> SIGSEGV

The guest has no LSI HBA (see env.txt), so — exactly like the DF-1556 and DF-1557 precedent — the harness reproduces the kernel arithmetic and the device-write pattern in an unprivileged userland process: the 92-byte "kmalloc" is placed against a PROT_NONE guard page, the firmware DMA is modeled as a memcpy of cm_length bytes of firmware-chosen data. SIGSEGV on the guard page == the heap overflow primitive.

Fix validation

cc -O2 -Wall -Wextra -DFIXED -o harness_fixed harness.c
./harness_fixed 24   # exit 0, no overflow
./harness_fixed 255  # exit 0, no overflow
./harness_fixed 4    # short-page floor guard path (fix.diff hunk 2)

fix.diff (never applied to sys/) sizes the allocation MAX(cm->cm_length, MPS_MAN_PAGE10_SIZE) and rejects pages shorter than the ProductSpecificInfo[5] deref needs (0x1C bytes, mps_config.c:286,297).

Files

• harness.c — reproduction source (baseline + -DFIXED validation modes)
• run.sh — exact build/run commands
• run.log — FULL untrimmed guest output (build + decisive runs + fixed runs)
• env.txt — guest uname / compiler / mps-in-GENERIC / no-HBA proof
• fix.diff — git-apply-able fix vs sys/dev/raid/mps/mps_config.c
• VERDICT.md, manifest.json, verdict.json

DF-4363 VERDICT

Status: reproduced (harness, guest has no mps HBA — same method as DF-1556/DF-1557). Impact class: kernel heap overflow via device DMA (CWE-787). Primitive certain.

Root cause (line-accurate)

mps_config_get_man_pg10() at sys/dev/raid/mps/mps_config.c:181-314:

1. :248-249 — after the PAGE_HEADER round-trip, the firmware-supplied mpi_reply->Header.PageLength (U8, in the reply copied at :221) becomes cm->cm_length = le16toh(PageLength) * 4 → up to 1020.
2. :254 — the page buffer is allocated at the fixed size MPS_MAN_PAGE10_SIZE = 0x5C = 92 bytes (mpsvar.h:105), the only fixed-size page allocation in the file. Every other getter allocates cm->cm_length (mps_config.c:136,607,730,852,970,1089,1209,1354), and every getter in the successor driver does the same (mpr_config.c:145,277,450,588,724,861,998,1130,1262,1394,1552).
3. :260-261 — cm->cm_data = page; mps_request_polled(sc, cm); with MPS_CM_FLAGS_DATAIN: mps_map_command (mps.c:2099-2101) loads bus_dmamap_load(..., cm->cm_data, cm->cm_length, ...). busdma does not know the malloc size — it maps cm_length bytes starting at the 92-byte allocation, and mps_data_cb (mps.c:2041ff) builds SGEs covering the whole map. The IOC then DMAs the full Manufacturing Page 10 into it.

Result: firmware-controlled heap overflow of up to 928 bytes past a 92-byte M_MPT2 allocation, with fully controlled content (the page bytes), at kfetch/malloc heap in the config path.

The in-function derefs are NOT the bug: page->ProductSpecificInfo (offset 0x04, :286) and pPS_info[5] (0x18, :297-298) both sit inside 0x5C (Mpi2ManufacturingPagePS_t, mpi2_cnfg.h:722-727). The bug is purely the DMA-length vs allocation-size mismatch — which is why this is distinct from the knowns DF-1556 (:1117 missing-MIN bcopy) and DF-1557 (:462 PhysDiskMap index): neither covers this site.

Reachability

• Attach/discovery on WarpDrive HBAs: mps_pci.c:143 ("LSI SSS6200" → MPS_FLAGS_WD_AVAILABLE) → mps_sas.c:3320 mps_wd_config_pages() → mps_config.c:368 mps_config_get_man_pg10().
• Threat model identical to DF-1556/DF-1557 (both rated High, this file): malicious/buggy firmware or a device posing as an SSS6200 (PCIe hotplug). Not reachable from an unprivileged process without such hardware — hence harness-level reproduction, per the established DF-1556/DF-1557 precedent.

Reproduction (guest, unprivileged user maxx)

Guard-page harness mirrors the kernel arithmetic 1:1; the device DMA is a memcpy of cm_length firmware-chosen bytes into a 92-byte buffer placed at the end of a page followed by PROT_NONE:

• PageLength=24 → cm_length=96 → SIGSEGV, 4 bytes past the allocation (minimal case) — run.log RUN24_EXIT=1
• PageLength=23 → cm_length=92 → exact fit, clean pass — RUN23_EXIT=0 (proves the boundary is exactly 0x5C)
• PageLength=255 → cm_length=1020 → SIGSEGV, 928 bytes past — RUN255_EXIT=1

Fix validation

fix.diff (authored against the read-only sys/ tree; NOT applied there): size the buffer MAX(cm->cm_length, MPS_MAN_PAGE10_SIZE) and reject cm->cm_length < 0x1C before the ProductSpecificInfo[] derefs. Modeled in the harness via -DFIXED:

• baseline: PageLength 24/255 → SIGSEGV (overflow) — reproduced
• fixed: PageLength 24/255 → exit 0, no overflow; PageLength 4 → EINVAL floor-guard path (protects the fixed allocation's own derefs)
• fix_status: fixed (harness-level; a real kernel build cannot exercise the driver without an HBA, and the two hunks are mechanical).

Guest left clean (no kernel changes, /tmp artifacts only); no panic.

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.