DF-5423 — root-hub usbconfig reset never returns: unkillable D4 process + permanent USB-subsystem wedge (u4b core, reproduced through the uftdi rig)

What (human-readable)

usbconfig -d ugen0.1 reset (reset of a root hub) with any device attached to that root hub:

• the usbconfig process enters state D4, wchan USBSLP and never returns — kill -9 cannot remove it;
• subsequent USB operations wedge too (usbconfig list hangs — the bus explore path is dead);
• the guest otherwise stays alive; only a reboot clears it.

Reproduced 3× (twice with an open/writing uftdi port, once with the port closed and the device merely attached — the open tty is not required). This matches the D4 hang the umodem.c pass-2 observed while probing this family; it is a u4b-core defect (usb_dev.c + usb_hub.c), with uftdi as the attached passenger device.

Root cause (path:line)

• The userland reset lands in the generic-usb ioctl path whose tail is sys/bus/u4b/usb_dev.c:1137-1149:

c /* Wait for re-enumeration, if any */ while (f->udev->re_enumerate_wait != USB_RE_ENUM_DONE) { usb_unref_device(cpd, &refs); usb_pause_mtx(NULL, hz / 128); /* "USBSLP", uninterruptible */ if (usb_ref_device(cpd, &refs, 1)) { err = ENXIO; goto done; } }

— an unbounded, uninterruptible spin-wait.

• For the root hub the flag is set by the reset ioctl (usb_generic.c:1801-1802, re_enumerate_wait = USB_RE_ENUM_START), but uhub_explore_handle_re_enumerate() — the only code that clears it (usb_hub.c:474,498,511,515) — is invoked only for hub children (usb_hub.c:550, inside uhub_explore's per-port loop). The root hub has parent_hub == NULL; nothing ever services its re_enumerate_wait, so the wait loop spins forever, one USBSLP sleep at a time. (usb_hub.c:461-467 already special-cases "the root HUB cannot be re-enumerated" — but that code is unreachable for the root hub itself.)

• The observed child detach/re-attach (dmesg: ugen0.2 (disconnected) → device still open, forcing close → detached → re-attach) comes from the root-hub power-mode change that the same ioctl triggers — cosmetic w.r.t. the hang.

Who can trigger

Root only (usbconfig reset needs the 0600 root ugen node). The wedge is system-wide and permanent though: one command kills the whole USB bus (hotplug, enumeration, new opens of usbconfig) until reboot, and leaves an unkillable D4 process.

Reproduce

usbconfig -d ugen0.1 reset        # any device attached to the root hub
ps -ax -o pid,stat,wchan,command | grep usbconfig
#   -> D4  USBSLP  usbconfig -d ugen0.1 reset
kill -9 <pid>                     # survives
usbconfig list                    # hangs

run.log is the clean 3rd reproduction (device attached, port NOT open): D4/USBSLP, kill -9 "Killed" yet the process still present, and usbconfig list hanging (the ssh session had to be cut by the operator).

Fix

fix.diff (usb_dev.c): bound the re-enumerate wait (~2 s of hz/128 sleeps → ETIMEDOUT), with a comment pointing at the unserviced root-hub flag. git apply --check passes against sys/. (A fuller fix would service the root hub's own re_enumerate_wait from the bus explore thread; the bound removes the unkillable-wedge failure mode either way.)

DF-5423 VERDICT — root-hub reset unkillable D4 wedge

Status: reproduced (3×; live on the guest: D4/USBSLP, SIGKILL-immune, USB subsystem wedged until reboot). Impact: dos (root-triggered; system- wide USB outage + unkillable process, reboot required). Confidence: certain.

Reproductions

1. (17:2x, with a 1 MiB write in flight on /dev/cuaU0): usbconfig -d ugen0.1 reset inside timeout 12 — the timeout's SIGTERM could not kill it; ps: 964 D1 USBSLP; kill -9 964 — process still present minutes later; later usbconfig list produced no output (hang).
2. (T4a, fresh boot, port closed, device merely attached): same command — 1075 D4 USBSLP; kill -9 reported "Killed" but ps still showed 1075 in D4; timeout 10 usbconfig list never produced output; guest ssh/uptime fine. → the open tty is NOT a precondition; any child device on the root hub suffices. This run is run.log.
3. (first observation, 17:1x): identical with the writer hung.

This is the same D4 hang the umodem.c pass-2 run observed while probing this family; it is not driver-specific (the uftdi port was closed in reproduction 2).

Root cause (path:line) — see README.md

• Unbounded uninterruptible wait: sys/bus/u4b/usb_dev.c:1139-1149 (while (f->udev->re_enumerate_wait != USB_RE_ENUM_DONE) usb_pause_mtx (NULL, hz/128) — wchan USBSLP, usb_util.c:134).
• The waited flag is set for the root hub by the reset path (usb_generic.c:1801-1802) but only hub children are ever serviced (sole clear sites usb_hub.c:474/498/511/515, reached only from the per-port call at usb_hub.c:550). Root hub has parent_hub == NULL (usb_hub.c:461-467's own "cannot reset root HUB" branch proves the authors knew, yet the flag is still left pending) → the wait never ends.

Impact ceiling

Root-only trigger (ugen node 0600), but the failure is a permanent, reboot-required, whole-bus outage plus a SIGKILL-immune process — a foot-gun for any admin script that touches root-hub reset (and the same wait loop is reachable for non-root devices where the explore thread CAN service the flag, so the unbounded loop remains a latent hazard for wedged explore threads, e.g. when combined with DF-5422's close hang holding the explore path).

Fix validation

fix.diff bounds the loop (256 × hz/128 ≈ 2 s → ETIMEDOUT). git apply --check passes; not boot-tested (full kernel rebuild out of scope for this pack) — fix_status not_testable, mechanism trivial by inspection (adding a loop bound cannot leave the wait longer).

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.