DF-3932 — mly: MLYIO_COMMAND size handling — INT_MIN negation panics kmalloc; unbounded sizes; ignored dmamap_load failure

Build / Run

Sink proof (done, on the audit guest)

The exact kmalloc the ioctl path performs was executed via a kernel-module replica (kmallocsink_replica.c, in this pack):

build: see build.log (guest cc 8.3, -Werror; note the compiler itself flagged the size 18446744071562067968 as exceeding max object size — same value mly.c:2889 computes) run: kldload kmallocsink.ko; sysctl kern.kmallocsink=1 expected + observed: panic "kmem_slab_alloc(): kernel_map ran out of space!" (panic.txt, run.log) — guest died, reset afterwards.

Full trigger (hardware-gated, on a machine with /dev/mly0)

#include ; #include #include "mlyio.h" / struct mly_user_command; MLYIO_COMMAND / struct mly_user_command uc; memset(&uc, 0, sizeof(uc)); uc.DataTransferLength = -2147483647 - 1; / INT_MIN / int fd = open("/dev/mly0", O_RDWR); / 0600 root:operator / ioctl(fd, MLYIO_COMMAND, &uc); / -> kernel panic /

Expected result

Kernel panic (proven at the sink level on this guest; the ioctl trigger itself needs the mly device node that only exists with the hardware).

See VERDICT.md.

DF-3932 verdict narrative

Reproduced?

The sink is reproduced on the audit guest kernel: executing the exact kmalloc(0xffffffff80000000, M_DEVBUF, M_INTWAIT) that mly_user_command performs for DataTransferLength == INT_MIN panics the kernel with "kmem_slab_alloc(): kernel_map ran out of space!" (panic.txt; trace fire_sysctl → _kmalloc → kmem_slab_alloc). The trigger (MLYIO_COMMAND ioctl on /dev/mly0) is hardware-gated — no mly controller in the guest — so the finding as a whole is filed inconclusive (mechanism proven, instance hardware-gated), following the DF-3715 family convention.

Root cause chain (path:line)

1. mlyio.h:42 — DataTransferLength is a plain signed int, fully user-controlled through the 0600 root:operator control device.
2. mly.c:2889 c mc->mc_length = (uc->DataTransferLength >= 0) ? uc->DataTransferLength : -uc->DataTransferLength; For INT_MIN the negation wraps (int overflow) and the sign-extension into size_t mc_length yields 0xFFFFFFFF80000000 — which satisfies mc->mc_length > 0 at mly.c:2890.
3. mly.c:2891 mc->mc_data = kmalloc(mc->mc_length, M_DEVBUF, M_INTWAIT); → kern_slaballoc.c:942 size >= ZoneLimit → kmem_slab_alloc → vm_map_findspace fails → kern_slaballoc.c:1724 panic (M_INTWAIT has no M_NULLOK). Proven on-guest (panic.txt).
4. Secondary defects in the same size handling (source-certain, folded here): - No upper bound at all: any root user can request up to 2GB-1 of WIRED kernel memory per ioctl (M_INTWAIT → kmem_slab_alloc wires it), repeatable — trivial kernel-memory exhaustion by the management daemon. - mly.c:1850 ignores bus_dmamap_load()'s error; on this DFly bus_dma the callback is always invoked (busdma_machdep.c:767-805) with the error passed in, and mly_map_command_sg (mly.c:1781) ignores its error argument too — a failed/partial load (EFBIG for >MAXBSIZE buffers, which the missing cap makes reachable) still dispatches the command with whatever stale s/g entries the slot's table holds.

Threat model

Root-only device node — the panic/DoS primitive is already-privileged (severity Low accordingly); the defect matters for robustness of the management stack (linux-mly-compatible tools pass user lengths straight through) and because the panic is reachable from a single ioctl with no hardware preconditions beyond the card being present.

Impact

Kernel panic (DoS), proven at the sink on this guest kernel; wired-memory exhaustion variant; stale-s/g dispatch variant.

Fix

Reject INT_MIN and cap |DataTransferLength| at MAXBSIZE (the buffer DMA tag's maxsize) — fix.diff.

Fix validation

Not run (fix touches mly path; hardware-gated). The kmallocsink replica already demonstrates that the size never reaching kmalloc removes the panic; the cap also makes bus_dmamap_load's EFBIG path unreachable.

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.