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