DF-5422 — ucom/uftdi TX close race: write(2)+close(2) wedges the closer in ttywait forever, only the first 64-byte packet is transmitted

What (human-readable)

Writing more than one USB transfer's worth of data (UFTDI_OBUFSIZE = 64, uftdi.c:82) to /dev/cuaU0 and closing the descriptor immediately makes close(2) sleep forever (wchan ttywai, tty.c:1396-1398) — and the data beyond the first 64-byte bulk-OUT packet is never transmitted (verified host-side through the QEMU usb-serial chardev socket).

Trigger is a race: the closer's ttywait competes with the asynchronous USB TX drain. Reproduced 10+ times on the live rig; hangs observed for every size from 64/65 up to 1 MiB; with a settle delay (≥1 s of ioctl polling or a plain sleep) before close, the same writes drain and close cleanly.

Who can trigger

• Any local user able to open /dev/cuaU* (mode 0660 uucp:dialer, usb_serial.c:483-488 — the standard serial-user group) — root trivially.
• Amplified by an evil USB device: a physical FTDI-alike that NAKs the bulk-OUT endpoint (or stalls it) makes the race deterministic — the TX queue can never drain, so every write+close wedges, with no timing window needed.
• After one wedged close the port is typically left in a polluted state (subsequent sessions block on carrier / behave erratically) until replug.

Root cause (path:line)

• ucom_close() — sys/bus/u4b/serial/usb_serial.c:938-978 — queues the cfg_close message and waits only for that message to run (usb_proc_mwait inside ucom_queue_command, usb_serial.c:671-672, invoked at 955-957). It does not wait for the tty output queue to drain. The async WR-xfer completion chain (uftdi_write_callback → ucom_get_data, 64 bytes per transfer) is still mid-drain when the close proceeds.
• sc->sc_flag &= ~UCOM_FLAG_HL_READY at usb_serial.c:959 turns ucom_start() into a no-op (early return at usb_serial.c:1734-1739), so the t_oproc that ttywait() calls each iteration (tty.c:1392) can no longer submit transfers.
• (*linesw[tp->t_line].l_close)(tp, 0) (usb_serial.c:966) → ttylclose() (tty.c:1562) → ttywflush() → ttywait() (tty.c:1384-1406) sleeps on TSA_OCOMPLETE with no timeout (tp->t_timeout == 0). Nothing in the ucom TX-completion path ever calls ttwwakeup(), so the sleeper is never woken even if the queue would eventually drain; QEMU tracing shows the bulk-OUT chain goes fully idle at close time (zero USB packets while hung), so the outq is frozen permanently.
• ucom_get_data() (usb_serial.c:1844-1942) — the only consumer of t_outq — never signals TSA_OCOMPLETE/TSA_OLOWAT waiters when it empties the queue (missing ttwwakeup, contrast sio.c's TX-complete handler).

Reproduce (QEMU rig: qemu-xhci or piix3-usb-uhci + -device usb-serial)

# guest:
cc -O2 -o /root/uftdi_live /root/uftdi_live.c      # or ./build.sh
timeout 10 /root/uftdi_live w 1024                  # or ./run.sh
# expect: no output, exit=124 (timeout had to SIGTERM it)
# while hung:  ps -ax -o pid,stat,wchan,command | grep uftdi_live
#   -> STAT I2/S*, WCHAN ttywai
# host side (chardev socket byte counter): only +64 bytes ever arrived.

Control runs in run.2.log / VERDICT.md: sizes 64..1024 all hang; uftdi_probe2 1024 0 1 0 1 (2 s settle + TIOCOUTQ polling) drains to 0 and closes in 0 ms; RX direction works (10/10 bytes delivered with the 2-byte FTDI status header stripped by uftdi_read_callback, uftdi.c:427-491).

Fix

fix.diff (usb_serial.c): (1) drain t_outq in ucom_close() while t_oproc is still live, bounded by tp->t_timeout so an evil/dead device cannot wedge close(2) indefinitely; (2) ttwwakeup(tp) from ucom_get_data() when the TX queue empties, giving ttywait drain-waiters their wakeup. git apply --check passes against sys/.

DF-5422 VERDICT — ucom/uftdi TX close race (ttywai hang)

Status: reproduced (live device traffic on the QEMU usb-serial rig bound to uftdi; 10+ hangs across runs). Impact: dos (local; hang of the closing process + TX data loss + port pollution until replug; deterministic with an evil/dead device). Confidence: certain.

Rig

QEMU 7.2 -device usb-serial (presents FTDI 0403:6001 FT232BM, including the 2-byte FTDI IN status headers and the FTDI vendor control requests) on a piix3-usb-uhci controller; host-side chardev socket daemon injects RX and counts TX. Guest: DragonFly 6.5-DEVELOPMENT X86_64_GENERIC (env.txt). uftdi0 attaches, /dev/cuaU0 (0660 uucp:dialer) appears.

Reproduction

• run.log — timeout 10 /root/uftdi_live w 1024: 10.05 s real, exit 124 — close(2) never returned; timeout(1) had to kill the process. Earlier live captures of the same state show ps STAT I2/S* WCHAN ttywai — the ttysleep(..., "ttywai", tp->t_timeout) at sys/kern/tty.c:1396-1398 inside ttywait().
• run.2.log — size sweep: n=64/65/128/1024 all hit the 6 s timeout (rc=124) in the later (warmer) port state; in the fresh-boot state the boundary was >64 bytes (6/6 hangs at 65..1024, one-buffer 64 usually completing) — consistent with a close-vs-drain race whose window shifts with taskqueue/USB timing, not with a fixed size check.
• Host-side TX counter (chardev socket): during a 1024-byte hang exactly +64 bytes arrived — one UFTDI_OBUFSIZE transfer (uftdi.c:82,403). The remaining 960 bytes never reach the wire.
• QEMU packet tracing (earlier boot, -trace usb_packet_state_change): trace line count frozen across the hang window (118553 → 118553 over 6 s) — the bulk-OUT chain is fully idle while the closer sleeps; nothing is draining, nothing can wake TSA_OCOMPLETE.
• Controls: uftdi_probe2 1024 0 1 0 1 (write, 2 s settle, TIOCOUTQ polls, CLOCAL) — outq drains to 0, closed in 0 ms; 200-byte blocking variant also drained (nopoll outq=0, closed 0 ms). RX path verified good: 10 host-injected bytes delivered intact (414243..., 2-byte status header stripped per packet by uftdi_read_callback, uftdi.c:442-476). Baseline open/param/close on the good device: open ≈ 0 ms, tcsetattr ≈ 0 ms, close ≈ 330-390 ms (the synchronous cfg-chain wait — see DF-5424).

Why it hangs (path:line)

1. Writer: write(2) queues N>64 bytes into tp->t_outq (ttwrite, tty.c:1988+); the WR xfer drains 64 bytes per completion (uftdi_write_callback → ucom_get_data, uftdi.c:390-424 / usb_serial.c:1844-1942) — but only once the open/param cfg tasks have set UCOM_FLAG_GP_DATA (usb_serial.c:727-728), ~350 ms after open.
2. close(2) → ucom_dev_close → ucom_close (usb_serial.c:938): - 955-957: queues cfg_close and usb_proc_mwaits for the message only — not for the outq drain; the async drain is still running. - 959: clears UCOM_FLAG_HL_READY → ucom_start() no-ops (usb_serial.c:1734-1739) → t_oproc is dead for ttywait. - 966: l_close → ttylclose (tty.c:1562) → ttywflush → ttywait (tty.c:1384-1406): sleeps on TSA_OCOMPLETE with tp->t_timeout == 0 (no timeout).
3. Nobody ever calls ttwwakeup() on TX completion (ucom_get_data lacks it; ucom_start is dead), and the USB WR chain has gone idle (QEMU trace frozen) — the sleep is permanent. PCATCH makes SIGTERM/SIGKILL able to kill the process, but the port is left polluted (later sessions were observed blocking on carrier ttydcd / misbehaving until replug).

Not a uftdi.c-local defect: the driver's callback is the stock FreeBSD u4b code; the bug is the DragonFly ucom core's close/drain ordering (usb_serial.c:955-975) plus the missing TX-complete wakeup. It manifests through every ucom-family driver; uftdi is the one bindable on this guest.

Exploit chain (impact ceiling)

Local: user with dialer-group access (or root) runs the 3-line trigger — process wedged in close(2) forever, 15/16 of a 1 KiB write silently lost, port degraded until replug; repeatable. Physical/evil-USB: an FTDI-alike that NAKs bulk-OUT (or is unplugged mid-write in the right window) removes the race — every write+close wedges. No memory-safety primitive observed (the hang is a logic/lifecycle bug; the uftdi data path itself is memory-safe under the live rig — RX/TX contents verified byte-exact).

Fix validation

fix.diff reorders/bounds the close (drain while t_oproc is alive, tp->t_timeout bounded; add the missing ttwwakeup on final drain). Authored against read-only sys/, git apply --check passes. Not boot-tested (would require a full GENERIC kernel rebuild; fix_status not_testable) — mechanism argued line-by-line above.

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.