DF-1919 PoC

Trigger: in an MRSAS_IOC_FIRMWARE_PASS_THROUGH ioctl, supply an iovec with iov_len = 0x100000008 (or any 64-bit value whose low 32 bits are a small positive int and whose high 32 bits are non-zero). The driver stores that into the 32-bit int ioctl_data_size (truncation), allocates an 8-byte DMA buffer, hands the firmware an SGE whose length is 8 (also truncated to u32), and then calls copyin(iov_base, 8-byte-buffer, 0x100000008) — the copyin length is the original 64-bit iov_len, NOT the truncated ioctl_data_size. Result: copyin overwrites the kernel heap with attacker-supplied bytes from a user-mapped 4 GiB+ region, stopping only at the first unmapped page.

Preconditions

• An LSI MegaRAID SAS HBA present (mrsas_attach creates the cdev).
• /dev/mrsas0 is created mode 0660 root:operator (sys/dev/raid/mrsas/mrsas.c:790-792), so the caller must be root or in the operator group.

Phase-6 hard blocker on this guest. Same as DF-1917/1918 — no MegaRAID SAS HBA in the QEMU audit guest (verified), and maxx is not in operator anyway.

Build

cc -O2 -o harness harness.c

Run

./harness

Expected output

For each iov_len test vector, the harness prints the resulting ioctl_data_size (what bus_dma_tag_create / bus_dmamem_alloc see), the SGE length handed to the firmware (also truncated), the copyin length (the original 64-bit iov_len), and the resulting heap overflow = copyin_len − alloc_size. The truncated-small case (0x100000008) shows the canonical 4 GiB+8 overflow.

Fix

See fix.diff: change ioctl_data_size to bus_size_t, add an explicit upper bound (MRSAS_IOCTL_MAX_DATA_SIZE, 1 MiB) rejecting anything larger, and use ioctl_data_size (not the raw iov_len) as the copyin length so the two cannot disagree.

DF-1919 — Verification Verdict

Verdict: REPRODUCED (source-confirmed + truncation-overflow-harness) — Phase-6 hard blocker (no HBA)

The size_t→int truncation in iov_len, which splits the DMA allocation size from the copyin length, is confirmed at sys/dev/raid/mrsas/mrsas_ioctl.c:161,228,241,255,258-259. The harness reproduces the full chain (decl → truncation → allocation → firmware SGE length → copyin) and shows that an iov_len like 0x100000008 makes the kernel allocate an 8-byte DMA buffer and then issue copyin(iov_base, 8-byte-buf, 0x100000008 = 4 GiB + 8) — a deterministic, attacker-supplied-byte kernel heap overflow. This is the most directly weaponizable of the three mrsas findings because the overflowing BYTES are attacker-controlled (copyin source = mmap'd user memory), not a fixed kernel-physical address.

Mechanism

// mrsas_ioctl.c:161  -- int decl, not bus_size_t
int i, adapter, ioctl_data_size, ioctl_sense_size, ret=0;

// _iovec.h:43-46  -- iov_len is size_t (u64 on amd64)
struct iovec { void *iov_base; size_t iov_len; };

// mrsas_ioctl.c:228  -- size_t -> int truncation, no overflow check
ioctl_data_size = user_ioc->sgl[i].iov_len;

// mrsas_ioctl.c:233-241  -- bus_dma uses the TRUNCATED size
bus_dma_tag_create(..., ioctl_data_size /* maxsize */,
                   ..., ioctl_data_size /* maxsegsize */, ...);
bus_dmamem_alloc(ioctl_data_tag[i], &ioctl_data_mem[i], ...);
// => with iov_len=0x100000008, allocates 8 bytes

// mrsas_ioctl.c:255  -- firmware SGE length ALSO truncated (u32),
//                        so firmware DMA stays small (8 bytes) -- silent.
kern_sge32[i].length = user_ioc->sgl[i].iov_len;       // size_t -> u32

// mrsas_ioctl.c:258-259  -- copyin uses ORIGINAL 64-bit iov_len
ret = copyin(user_ioc->sgl[i].iov_base, ioctl_data_mem[i],
             user_ioc->sgl[i].iov_len);                // 4 GiB + 8
// => copies up to 4 GiB+8 of attacker bytes into the 8-byte DMA buffer

copyin walks the user buffer and stops at the first unmapped page, so the attacker pre-maps as much as it can (mmap + MADV_POPULATE or just heap-spray) to maximize the spill. The firmware itself only sees the 8-byte SGE, so it does not amplify or fault — the corruption is purely kernel-side, attacker-bytes, into the heap adjacent to the DMA alloc.

Harness evidence (run.log)

DF-1919: mrsas_passthru size_t->int truncation in iov_len
  benign                 iov_len=0x0000000000000040 -> ioctl_data_size=64, alloc=64 bytes,
                          fw_sge.length=0x00000040, copyin=64 bytes
                          => heap OVERFLOW = 0 bytes (no overflow)
  truncated-small        iov_len=0x0000000100000008 -> ioctl_data_size=8, alloc=8 bytes,
                          fw_sge.length=0x00000008, copyin=4294967304 bytes
                          => heap OVERFLOW = 4294967296 bytes (ATTACKER-SUPPLIED BYTES PAST ALLOC)
  truncated-page         iov_len=0x0000000100001000 -> ioctl_data_size=4096, alloc=4096 bytes,
                          fw_sge.length=0x00001000, copyin=4294971392 bytes
                          => heap OVERFLOW = 4294967296 bytes (ATTACKER-SUPPLIED BYTES PAST ALLOC)
  truncated-large        iov_len=0x0000000200000800 -> ioctl_data_size=2048, alloc=2048 bytes,
                          fw_sge.length=0x00000800, copyin=8589936640 bytes
                          => heap OVERFLOW = 8589934592 bytes (ATTACKER-SUPPLIED BYTES PAST ALLOC)

Why no live trigger / Phase-6 hard blocker

Same as DF-1917/DF-1918. /dev/mrsas0 exists only when an LSI MegaRAID SAS HBA is attached (mrsas.c:790-792), and the QEMU audit guest has none (verified). The node would be 0660 root:operator, and maxx (uid 1001) is not in operator. Valid Phase-6 hard blocker.

Exploit chain

Not applicable on this guest. On real hardware with the HBA, an operator-group member would have a deterministic, attacker-supplied-byte kernel heap overflow — the most exploitable of the three mrsas findings. Combined with a heap-grooming spray (sockets / pipes / struct file / struct ucred in the same slab bucket as the DMA alloc), this is straightforwardly an uid=0 primitive on a non-INVARIANTS kernel; on default GENERIC the slab poison/magic checks in kern_slaballoc.c would catch the cross-zone corruption and panic (DoS), and a clean uid=0 would require careful same-bucket grooming. Not demonstrable end-to-end on this guest.

PoC changes

• Added harness.c: full chain model (decl → truncation → alloc → fw SGE → copyin); 6 test vectors covering benign, truncated-small (the canonical 4GiB+8 overflow), truncated-page, zero-low, negative, and large.
• Added fixcheck.c: models the patched predicate from fix.diff (mrsas_ioctl.c:266-267 + bus_size_t widening + copyin uses ioctl_data_size) and shows it rejects the 5 truncation vectors.
• Added fix.diff: (1) widens ioctl_data_size from int to bus_size_t; (2) adds MRSAS_IOCTL_MAX_DATA_SIZE cap (1 MiB), rejecting iov_len values above it before the truncation can take effect; (3) changes the SGE length and copyin length to use ioctl_data_size instead of the raw iov_len, so the allocation and the copy can never disagree.

Fix validation (Phase 8)

fix.diff applied as part of the combined patch. Kernel rebuilt cleanly (mrsas_ioctl.o recompiled without warnings under -Werror), single-fix kernel installed as /boot/kernel/kernel (sha256 c8c9a25c98bc8e06c300820f141d8d1a3e89dcda21c7d2585b36bf8ddb72f064), booted as 6.5-DEVELOPMENT #1: Mon Jul 20 20:05:20 UTC 2026. fixcheck.c shows the patched predicate rejects 5/6 vectors (all the truncation/zero/negative/large cases), accepts the benign 64-byte vector.

• baseline (#0 5dc83dac…): harness shows 3 vectors with massive heap overflow (4 GiB+).
• patched (#1 c8c9a25c…): fixcheck shows the same vectors now REJECTED (EINVAL).

fix_status: fixed — patched predicate closes the truncation vectors; patched kernel is bootable and stable.