DF-3950 — mlx_wait_command(): timeout counter never incremented → unkillable infinite wait

Severity: Low · CWE-835 (loop without exit) · operator/root gated (MLX_COMMAND path; also hit by MLXD_CHECKASYNC / MLX_REBUILDASYNC ioctls and synchronous mlx_enquire calls)

Bug

sys/dev/raid/mlx/mlx.c:1655-1659:

    count = 0;
    /* XXX better timeout? */
    while ((mc->mc_status == MLX_STATUS_BUSY) && (count < 30)) {
    tsleep(mc->mc_private, PCATCH, "mlxwcmd", hz);
    }

count is declared (1646) and tested, but never incremented — the loop condition count < 30 is always true while the command stays busy. If the controller never posts a completion (wedged HBA, pulled enclosure, firmware hang), the calling thread sleeps 1s at a time forever. PCATCH lets a signal interrupt each individual tsleep, but the loop immediately re-enters — the thread can never make progress or exit; the ioctl never returns. The timeout stamp mc->mc_timeout = time_uptime + 60 set in mlx_start() (mlx.c:2086) is documented "XXX not currently used" and indeed nothing consumes it (grep-verified).

Contrast mlx_poll_command() (mlx.c:1689-1694) which correctly does count++ < 15000000.

Reachability

Any MLX_COMMAND passthrough whose firmware command never completes, or MLXD_CHECKASYNC/MLX_REBUILDASYNC against a stuck controller. Requires a wedged/unresponsive DAC960 — hence Low (privileged user + flaky hardware), but the defect is unconditional in the code path.

Build / Run / Expected

cc -O2 -Wall -o mlx_ioctl_trigger mlx_ioctl_trigger.c
./mlx_ioctl_trigger usercmd /dev/mlx0     # against a controller that hangs

Expected on hardware: ioctl never returns; ps shows the caller stuck in mlxwcmd forever; SIGKILL does not reclaim the thread. On this guest: ENOENT (no HBA) — hardware-gated.

Fix

Increment count each iteration (and abort with EIO after the 30s budget), matching the poll path; see fix.diff.

DF-3950 — Verification Verdict

Status: inconclusive (hardware-gated; source-certain) Impact demonstrated: none (expected: permanent unkillable thread hang) Confidence: certain (source), runtime untestable (no DAC960 HBA)

Source proof

• sys/dev/raid/mlx/mlx.c:1646 declares int error, count;
• sys/dev/raid/mlx/mlx.c:1655-1659: loop while ((mc->mc_status == MLX_STATUS_BUSY) && (count < 30)) tsleep(mc->mc_private, PCATCH, "mlxwcmd", hz); — count has no increment anywhere in the function (grep: the only writes are the initializer at 1655). PCATCH breaks a single tsleep on signal, then the (unchanged) condition re-sleeps — no exit.
• mlx_start() sets mc->mc_timeout = time_uptime + 60 (mlx.c:2086) with the comment "XXX not currently used"; no consumer exists.
• Callers: mlx_user_command (mlx.c:1922), mlx_check (mlx.c:1577), mlx_rebuild (mlx.c:1620), synchronous mlx_enquire (mlx.c:1486) — i.e. every wait-style ioctl submission.

Impact: thread permanently resident in kernel ("mlxwcmd") — a local operator/root-triggered DoS of the calling process (unkillable) and of the controller's command path. Not memory corruption.

Guest result

Trigger compile-tested (BUILD_RC=0 on DragonFly 6.5-DEVELOPMENT); runtime ENOENT — no Mylex hardware. Honest: inconclusive / source-certain.

Fix validation

fix.diff adds the missing increment + failure return. Not runtime-testable here (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.