DF-4009 — mpr NVMe-encapsulated pass-thru: unbounded DataSize drives PRP walk past the arena (OOB write)

What

mpr_user_pass_thru() (sys/dev/raid/mpr/mpr_user.c:740) takes the user's DataSize/DataOutSize (raw uint32_t from mpr_pass_thru_t) and, when the request's Function byte is MPI2_FUNCTION_NVME_ENCAPSULATED (0x33 — a byte the user fully controls in the request header, checked at mpr_user.c:945), calls:

mpr_build_nvme_prp(sc, cm, nvme_encap_request, cm->cm_data,
    data->DataSize, data->DataOutSize);          /* mpr_user.c:970 */

cm->cm_data was allocated as kmalloc(MAX(DataSize, DataOutSize)) — with the result never checked (mpr_user.c:904-914): a size the kernel cannot satisfy leaves cm->cm_data == NULL, and the PRP build still runs.

mpr_build_nvme_prp() (sys/dev/raid/mpr/mpr.c:2680-2864) translates the length into a linear walk of 8-byte PRP entries through one contiguous arena and never bounds-checks the walk against the arena end — it relies entirely on length being sane:

while (length) {                                  /* mpr.c:2757 */
        ... *prp_entry = htole64(paddr); prp_entry++; prp_entry_phys++; ...
        if (entry_len > length) length = 0; else length -= entry_len;
}

The arena is PAGE_SIZE * ((maxio/PAGE_SIZE)/511 + 1) * NVME_QDEPTH (mpr.c:1593-1598) with NVME_QDEPTH = MPR_REQ_FRAMES = 2048 (mprvar.h:40,59) — 8 MiB for any maxio ≤ ~2 MB. The number of entries needed for length L is ceil(L/4096) + ceil(L/4096)/511 (one extra list pointer per full PRP page, mpr.c:2765-2783). For L = 0xFFFFFFFF that is 1,050,625 entries = 8,405,000 bytes > the 8,388,608-byte arena — the walk runs 16,416 bytes past the end even from chunk 0, and since the walk may begin at an arbitrary free chunk (mpr_alloc_prp_page, mpr.c:2716), starting from a higher chunk index overruns proportionally more — up to ~8.2 MB of OOB write when the first allocated chunk is near the end of the arena (see replication_run.log). The walk happens before mpr_wait_command() (mpr_user.c:1050) — no firmware cooperation is needed; the only gate is the driver being attached (arena allocated at attach).

Written values are semi-controlled: paddr starts at (bus_addr_t)(uintptr_t)data (mpr.c:2750) — the kernel virtual address of cm->cm_data (or 0 when the kmalloc failed / was skipped) — and increments by 4096 per entry. Deterministic, groomable length; 8-byte aligned writes.

Trigger (privileged surface)

/dev/mprN 0640 root:operator (mpr_user.c:205); O_RDONLY open + ioctl suffices (ioctls not gated on open mode — demonstrated live in the DF-1326 replica run on the same node mode). One ioctl(MPTIOCTL_PASS_THRU, {Function=0x33, DataDirection=READ, DataSize= 0xFFFFFFFF, PtrRequest->...}) from an operator-group user. Note cm->cm_length = MAX(DataSize, DataOutSize) with DataSize=0xFFFFFFFF → kmalloc of 4 GB fails fast on this class of machine → cm->cm_data=NULL → paddr=0 → the walk still writes 1M+ entries. (A smaller DataSize with a successful kmalloc writes KVA-derived values instead.)

Replication (guest, userspace arithmetic-level)

prp_overwalk.c replicates the walk/arena arithmetic verbatim (replication_run.log on 6.5-DEVELOPMENT):

maxio=128KB -> pages_required=1 arena=8388608 bytes (1048576 entries)
  DataSize=4294967295 start_chunk=0    walk=8405024 in_arena=8388608 OOB=16416   <== OOB WRITE
  DataSize=4294967295 start_chunk=512  ...                                 OOB=2113568 <== OOB WRITE
  DataSize=4294967295 start_chunk=2000 ...                                 OOB=8208416 <== OOB WRITE
  DataSize=1073741824 start_chunk=1536 ...                                 OOB=4104    <== OOB WRITE

Hardware gate & fix

Live trigger requires an mpr-attached controller with the NVMe-encapsulated path compiled in (any SAS3 with NVMe support; the build of the PRP list needs no FW round-trip). Fix: validate DataSize/DataOutSize against sc->maxio before building (reject > maxio), check the kmalloc result, and add an arena-end guard in the walk (prp_entry vs prp_page + pages_available).