DF-3949 — MLX_NEXT_CHILD NULL dereference (mlx_sysdrive[0] vs [i])

Severity: Low · CWE-476 · operator/root gated (/dev/mlxN is 0600 root:operator, mlx.c:466-468)

Bug

sys/dev/raid/mlx/mlx.c:746-761 — MLX_NEXT_CHILD walks the attached system drives. When the caller asks for the first child (*arg == -1) the code takes the unit number from sc->mlx_sysdrive[0].ms_disk instead of the drive it just found (sc->mlx_sysdrive[i].ms_disk):

for (i = 0; i < MLX_MAXDRIVES; i++) {
    if (sc->mlx_sysdrive[i].ms_disk != NULL) {
        if (*arg == -1) {
            *arg = device_get_unit(sc->mlx_sysdrive[0].ms_disk);  /* [0]! */
            return(0);

If system drive 0 has no child while a later drive does, this calls device_get_unit(NULL) → return(dev->unit) (sys/kern/subr_bus.c:1646-1649) → NULL dereference → kernel panic.

Reachability

mlx_startup() only creates children sequentially up to the sd_size == 0xffffffff sentinel, so on a plain boot [0] is attached whenever any later drive is. The state is produced by MLX_DETACH_DRIVE on system drive 0 (mlx.c:774-804): mlx_findunit() locates drive 0, the child is deleted and dr->ms_disk = NULL (mlx.c:796), while drive 1+ stays attached. The very next MLX_NEXT_CHILD(-1) — e.g. from mlxcontrol-style management tooling enumerating drives after a detach — panics the kernel. (RESCAN_DRIVES after config changes can also produce holes.)

Build / Run / Expected

cc -O2 -Wall -o mlx_ioctl_trigger mlx_ioctl_trigger.c
./mlx_ioctl_trigger nextchild /dev/mlx0     # detach drive0, then NEXT_CHILD(-1)

Expected on hardware: immediate kernel panic in device_get_unit (NULL+offset read). On this audit guest: ENOENT (no DAC960 HBA) — hardware-gated.

Fix

Use the drive actually found: device_get_unit(sc->mlx_sysdrive[i].ms_disk).

DF-3949 — Verification Verdict

Status: inconclusive (hardware-gated; source-certain) Impact demonstrated: none (expected: kernel panic) Confidence: certain (source), runtime untestable (no Mylex DAC960 HBA in QEMU guest)

Source proof

1. Copy-paste index bug: sys/dev/raid/mlx/mlx.c:753 *arg = device_get_unit(sc->mlx_sysdrive[0].ms_disk); inside the loop that just verified sc->mlx_sysdrive[i].ms_disk != NULL (mlx.c:750). Should be [i].
2. State producer: MLX_DETACH_DRIVE (mlx.c:774-804) deletes the child of the requested drive and sets dr->ms_disk = NULL (mlx.c:796); drive 0 can be detached while later drives remain attached.
3. device_get_unit is a direct deref: sys/kern/subr_bus.c:1646-1649 int device_get_unit(device_t dev) { return(dev->unit); } → NULL+offset read → kernel page fault.
4. Privilege: /dev/mlxN created UID_ROOT, GID_OPERATOR, S_IRUSR|S_IWUSR (mlx.c:466-468) — operator/root only ⇒ Low severity.

Guest result

Trigger compile-tested on DragonFly 6.5-DEVELOPMENT guest (BUILD_RC=0); runtime exits ENOENT — no DAC960 controller present. Honest classification: inconclusive, not false-positive (the path is fully live source; every hop cited).

Fix validation

fix.diff: one-token change [0] → [i]. Not runtime-testable on this guest (no HBA) → fix_status: not_testable.

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.