DF-5383 — umcs7840 cfg_open/cfg_close chain of up to 28/4 synchronous 500 ms EP0 requests stalls close(2) and unplug (hub event thread) for ~16 s

What (finding in one line)

umcs7840_cfg_open() (sys/bus/u4b/serial/umcs.c:410-515) performs 28 synchronous EP0 control requests on first open (2 global-config at umcs.c:423,426 + 14 port init at umcs.c:431-483 + 6 baud-rate writes at umcs.c:1022-1046 via umcs7840_set_baudrate(9600) at umcs.c:487 + 6 tail requests at umcs.c:496-512), each via usbd_do_request_proc() (umcs.c:927/948/972/997) with UMCS7840_CTRL_TIMEOUT = 500 ms (umcs.h:33). umcs7840_cfg_close() adds 4 more (umcs.c:527-534). A USB device may NAK the data stage of a control transfer arbitrarily long, so an evil MCS7840 can make every request succeed in just-under-500 ms without tripping the error-abort paths (cfg_open/cfg_close only abort on hard errors). The whole chain runs on sc_super_ucom.sc_tq (usb_serial.c:322), and tty close is synchronous against that queue: ucom_close() → ucom_queue_command(ucom_cfg_close) → usb_proc_mwait() (usb_serial.c:671-672) cv_wait()s uninterruptibly (usb_process.c:385-393) behind the still-running cfg_open. Unplug racing a cfg task stalls the same way through ucom_detach() → usb_proc_drain() (usb_serial.c:394) on the USB hub event thread — the DF-5367 (ufoma) mechanism, umcs instance. Worst case ~16 s uninterruptible stall per open/close cycle (28 + 4 requests × 500 ms, + hz/10 pause at usb_serial.c:777).

Evidence class

No MCS7840 device model on the QEMU guest (as uipaq/ufoma) → KLD harness built from production code: the real usb_proc_create/msignal/mwait machinery of ucom's taskqueue, with the per-request cost mirroring usbd_do_request_flags's WXFER sleep for a request the device stretches to just under the 500 ms timeout (usb_request.c:567-708).

Build

mkdir -p /usr/src/sys/bus/u4b/serial/hx5383
cp umcs_cfgstall_harness.c Makefile /usr/src/sys/bus/u4b/serial/hx5383/
sh build.sh          # in-tree kmod build, -Werror clean

Run

sh run.sh            # kldload ./umcscfgstall.ko; kldunload; dmesg

Expected output (decisive lines)

HX5383[A]: closer: queue cfg_close + usb_proc_mwait() (uninterruptible, usb_serial.c:671-672)
HX5383[A]: closer: unblocked  ELAPSED=15702 ms
HX5383[B]: closer: unblocked  ELAPSED=3228 ms

Phase A (500 ms/request, production constant) MUST show the closer blocked ~15.6-16 s. Phase B (fix mechanism from fix.diff: timeout bounded to 100 ms) MUST show ~3.2 s. run.log holds three loads: 15702/15707/15700 ms vs 3228/3232/3213 ms.

Fix validation

• fix.diff (against umcs.h) — git apply --check passes; patched driver compiles -Werror-clean as a kmod on the guest (fix_compile.log, RC=0).
• Harness Phase B shows the bounded-timeout mechanism: 15.7 s → 3.2 s.

Artifacts

• umcs_cfgstall_harness.c — the KLD harness (annotated with the umcs.c / usb_serial.c / usb_request.c lines it mirrors)
• Makefile, build.sh, run.sh
• build.log, fix_compile.log, run.log (decisive run, 3 loads), run.2.log, env.txt
• fix.diff — bound UMCS7840_CTRL_TIMEOUT to 100 ms with rationale
• VERDICT.md, manifest.json, verdict.json

DF-5383 VERDICT — umcs cfg_open/cfg_close sync-request chain stalls close(2)/detach ~16 s

Status: reproduced (mechanism level, production code) — impact: dos (evil USB device), no memory corruption.

The bug, link by link

1. The chain. umcs7840_cfg_open() issues these synchronous control requests in order (each = one EP0 round trip through umcs7840_get/set[_UART]_reg_sync() → usbd_do_request_proc()): umcs.c:423 (get CONTROL1, first open only), :426 (set CONTROL1, first open only), :431, :434, :437 (SP reset toggle), :441 (SCRATCH RS232), :445, :448 (CONTROLx RX-disable), :452 (IER=0), :456, :458 (FCR), :465 (LCR), :473 (MCR), :477, :480, :483 (FIFO reset), then umcs7840_set_baudrate(9600) at :487 → umcs.c:1022, 1027, 1033, 1037, 1040, 1046 (clock select + DLL/DLM), then :496 (get LCR), :498 (set IER), :503, :506 (CONTROLx RX-enable), :510 (LSR), :512 (MSR) — 28 requests on first open, 26 later. umcs7840_cfg_close() adds 4 (umcs.c:527, 528, 531, 534).

2. The timeout. Every request carries UMCS7840_CTRL_TIMEOUT = 500 ms (umcs.h:33). In usbd_do_request_flags() the requester sleeps in the "WXFER" loop (usb_request.c:642-644) until the transfer completes or the timeout fires (usb_request.c:700-704). USB permits a device to NAK the data stage indefinitely, so an evil device can make each request succeed just under the timeout — cfg_open's if (err) return; guards never fire, and the full chain costs ~28 × 500 ms ≈ 14 s (+ hz/10 trailing pause in ucom_cfg_open, usb_serial.c:777).

3. Who blocks. All cfg tasks run on the per-adapter ucom taskqueue sc_super_ucom.sc_tq (created at usb_serial.c:322; tasks execute serialized, message staying head-of-queue during execution, usb_process.c:146-158). * close(2) of the tty is synchronous: ucom_close() → ucom_queue_command(ucom_cfg_close) → usb_proc_mwait() (usb_serial.c:671-672) cv_wait()s — uninterruptibly (usb_process.c:385-393) — until the cfg_close message drains, i.e. behind the running cfg_open (14 s) plus cfg_close itself (4 × 500 ms ≈ 2 s) ≈ 16 s. * unplug racing an in-flight cfg task: umcs7840_detach() → ucom_detach() → usb_proc_drain() (usb_serial.c:394) — the USB hub event thread waits for the task to finish: same ~14-16 s per cycle (identical mechanism to DF-5367/ufoma, different driver and cause). * Reachability: open/close of /dev/ttyU* requires root/wheel (0600); /dev/cuaU* is 0660 uucp:dialer — a dialer-group user can drive the cycle; the pure evil-device variant needs no privileges at all, just insertion.

Why the harness is faithful

Production usb_proc_create/usb_proc_msignal/usb_proc_mwait are used verbatim (the same functions ucom's taskqueue and synchronous close use). Per-request cost mirrors a production "device stretches the data phase to just under the timeout": one lksleep(..., "WXFER", USB_MS_TO_TICKS(500)). Request counts (28 open + 4 close) are counted from the cited umcs.c lines. The closer thread reproduces usb_serial.c:671-672's mwait call pattern exactly.

Measured results (run.log, 3 module loads)

Expected ≈ 27×500 + 100 + 4×500 = 15600 ms (A) and ≈ 27×100 + 100 + 4×100 = 3200 ms (B). Match (the closer queues 100 ms into cfg_open).

Fix validation

• fix.diff bounds UMCS7840_CTRL_TIMEOUT to 100 ms (one-line change in umcs.h with rationale): worst-case open+close chain drops from ~16 s to ~3.2 s while staying ≫ a healthy device's control latency (µs-ms). Full remedy would additionally bound the whole cfg sequence; kept minimal here.
• git apply --check passes; patched driver (umcs.c + patched umcs.h) compiles -Werror-clean as a kmod on the guest (fix_compile.log).
• Harness Phase B: 15.7 s → 3.2 s.
• Scope caveat: mechanism + compile level (no MCS7840 device model on the guest), same sanctioned class as DF-5367.

Impact ceiling

Repeated ~16 s uninterruptible stalls of user threads closing the device and of the USB hub event thread during unplug, driven by an evil device (or a dialer-group user looping open/close); no memory corruption, no leak. Bounded per cycle, hence Low.

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.