# 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.