# 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`):

```c
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

```sh
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)`.