DF-5424 — uftdi cfg callbacks chain 2+3 sequential 1000 ms-timeout EP0 vendor requests with discarded errors: evil FTDI stretches every open to ~5.2 s and every tcsetattr to ~3.1 s of uninterruptible ucom-taskqueue occupancy (close(2)/unplug block behind it)

What (human-readable)

sys/bus/u4b/serial/uftdi.c issues sequential synchronous EP0 vendor control requests from its ucom cfg callbacks and discards every result (the ucom_cfg_do_request macro expands to usbd_do_request_proc(..., timo) — usb_serial.h:220-221 — and its usb_error_t return is unused at every call site):

• uftdi_cfg_param() (uftdi.c:665-703) — fired on every tcsetattr of an open tty — chains 3 requests: FTDI_SIO_SET_BAUD_RATE (680-686), FTDI_SIO_SET_DATA (688-694), FTDI_SIO_SET_FLOW_CTRL (696-702).
• uftdi_cfg_open() (uftdi.c:354-387) — every open(2) — chains 2 more: FTDI_SIO_RESET (364-370), FTDI_SIO_SET_FLOW_CTRL (374-380).
• uftdi_cfg_set_dtr/_rts/_break add 1 more each (uftdi.c:494-554).
• All with a 1000 ms timeout and no error-abort, exactly the family mechanism of DF-5367/DF-5383/DF-5407/DF-5421 (umcs7840/uplcom/uchcom).

An evil FTDI-alike (probe is a pure VID/PID table match, uftdi.c:205-269; any 0403:6001 or one of the ~45 OEM IDs) that never answers the control data stage makes each request eat its full timeout (usb_request.c:642-644 "WXFER" sleep, 699-704 timeout) and the chain marches on: ~5.2 s per open(2) (2+3 requests + 2×hz/10 ucom pauses), ~3.1 s per tcsetattr, ~8.2 s for two queued tcsetattr bursts (ucom's sc_param_task[2] double buffer). A device answering just-under-timeout makes every request succeed slowly — same cost, no error to abort on.

Who blocks

• The chain runs on the per-adapter ucom taskqueue (sc_super_ucom.sc_tq, usb_serial.c:322) holding sc->sc_lock.
• close(2) is synchronous against that queue: ucom_close() → ucom_queue_command(ucom_cfg_close) → usb_proc_mwait() — uninterruptible cv_wait (usb_process.c:385-393).
• Unplug stalls the USB hub event thread via ucom_detach() → usb_proc_drain() (usb_serial.c:394).
• Any local user with the tty open multiplies the occupancy (each tcsetattr re-queues the param task).

Reproduce (no evil-FTDI device model on the QEMU guest — its usb-serial

answers in µs — → KLD harness with production machinery, the mandated evidence class for this family)

sh build.sh    # in-tree kmod build, -Werror clean
sh run.sh      # kldload uftdicfgstall.ko; kldunload; dmesg | grep HX5424

Expected (dmesg)

HX5424[A]: closer: unblocked  ELAPSED=~5,000-5,400 ms  (open + 1 tcsetattr + close)
HX5424[2]: closer: unblocked  ELAPSED=~8,100-8,500 ms  (open + 2 tcsetattr + close)
HX5424[B]: closer: unblocked  ELAPSED=~2,100-2,400 ms  (fix.diff: abort on 1st error)

Measured: A = 5015 ms, A2 = 8139 ms, B = 2116 ms (run.log).

Live-device baseline (real QEMU FTDI, well-behaved): open ≈ 0 ms, tcsetattr ≈ 0 ms, close ≈ 330-390 ms — the synchronous chain wait is directly observable even with fast answers; the 1000 ms timeouts set the evil-device ceiling.

Fix

fix.diff — check the ucom_cfg_do_request return in uftdi_cfg_open and at each step of uftdi_cfg_param; abort the chain on the first failed request (silent device then costs 1 timeout ≈ 1 s per chain, not 5). git apply --check passes against sys/; the patched production driver compiles -Werror-clean as a kmod on the guest (fix_compile.log); the abort mechanism itself is validated by harness phase B (2116 ms vs 5015 ms).

DF-5424 VERDICT — uftdi cfg-chain synchronous-EP0 stall

Status: reproduced (mechanism-level, KLD harness with production taskqueue machinery — the mandated evidence class for this file, since the QEMU guest's usb-serial device model answers all control requests in µs and cannot model an evil FTDI). Impact: dos (evil-USB-adapter precondition + local tty user amplification). Confidence: certain.

Root cause (path:line)

• uftdi_cfg_param() — sys/bus/u4b/serial/uftdi.c:665-703 — issues 3 sequential synchronous vendor EP0 requests per tcsetattr: | step | request | lines | |---|---|---| | 1 | FTDI_SIO_SET_BAUD_RATE | 680-686 | | 2 | FTDI_SIO_SET_DATA | 688-694 | | 3 | FTDI_SIO_SET_FLOW_CTRL | 696-702 |
• uftdi_cfg_open() — uftdi.c:354-387 — 2 more per open(2): FTDI_SIO_RESET (364-370), FTDI_SIO_SET_FLOW_CTRL (374-380). (uftdi_cfg_set_dtr/rts/break add 1 each, uftdi.c:494-554.)
• Every request: ucom_cfg_do_request(sc->sc_udev, &sc->sc_ucom, &req, NULL, 0, 1000) — the macro is usbd_do_request_proc(..., timo) (usb_serial.h:220-221) — a 1000 ms synchronous control transfer whose usb_error_t return is discarded at every call site. No chain step can abort.
• Per-request worst case: the device never answers the data stage → the requester sleeps in the "WXFER" loop until the timeout fires (sys/bus/u4b/usb_request.c:642-644, 699-704) → USB_ERR_TIMEOUT, ignored by the driver; next request starts. A device answering just-under-timeout makes every request succeed at ~999 ms (no error path at all) — same cost.

Victim threads (why this is a DoS, not just slowness)

Identical to the filed family mechanism (DF-5367/5383/5407/5421): per-adapter ucom taskqueue under sc->sc_lock (usb_serial.c:322); synchronous uninterruptible close(2) (usb_serial.c:671-672, 955-957); hub-event-thread stall on unplug via usb_proc_drain (usb_serial.c:394); user-amplifiable via the sc_param_task[2] double buffer (usb_serial.c:1691-1693). /dev/cuaU* is 0660 uucp:dialer (usb_serial.c:483-488).

Reproduction (harness = production machinery + production numbers)

uftdi_cfgstall_harness.c uses the real usb_proc_create/msignal/mwait/ free machinery; each request is modeled at its exact production cost (lksleep("WXFER", 1000ms) — what usbd_do_request_flags charges for a never-answered control transfer); request counts 3 (param task) and 2 (open task) are uftdi's; the closer thread performs exactly ucom_close's synchronous usb_proc_mwait.

Measured (dmesg, run.log): * Phase A (open + 1 tcsetattr + close): 5015 ms * Phase A2 (open + 2 tcsetattr + close): 8139 ms * Phase B (fix.diff abort-on-first-error): 2116 ms

Live-device cross-check on the real QEMU FTDI (well-behaved): open ≈ 0 ms, tcsetattr ≈ 0 ms, close ≈ 330-390 ms (the synchronous chain wait, including the 2×hz/10 = 200 ms ucom pauses) — directly observed; the evil-device ceiling is the arithmetic of the five 1000 ms timeouts.

Fix validation

• fix.diff (uftdi.c): check ucom_cfg_do_request's return in cfg_open and at every cfg_param step; abort the chain on first failure.
• git apply --check passes against sys/ (host repo).
• The patched production driver compiles -Werror-clean as kmod uftdifix5424.ko on the guest (fix_compile.log; build method identical to DF-5407's uplcom fixed-driver compile check).
• Abort mechanism validated by harness phase B: 2116 ms vs 5015 ms (fix_baseline_reproduced=1, fix_patched_reproduced reflects the family pack convention; no full patched-kernel boot was performed).

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.