# DF-5504 VERDICT — ucycom cfg-stall (reproduced, mechanism-level)

## Finding

`ucycom_cfg_write()` (ucycom.c:412-444) issues ONE synchronous EP0
`SET_REPORT(feature)` per cfg callback via
`ucom_cfg_do_request(sc->sc_udev, &sc->sc_ucom, &req, sc->sc_temp_cfg, 0, 1000)`
(ucycom.c:438 — 1000 ms timeout) and DISCARDS the `usb_error_t`
("device request failed, err=%s (ignored)", ucycom.c:440-443). It is called from:

* `ucycom_cfg_open()` (ucycom.c:299-306) — every first `open(2)` of the tty
  (ucom core queues it at usb_serial.c:865-867 after a `cfg_param` task queued by
  the in-open `ucom_param()` call at usb_serial.c:842; that first param task
  no-ops before `UCOM_FLAG_LL_READY` is set — usb_serial.c:1626 — so the first
  open costs one request, not two);
* `ucycom_cfg_param()` (ucycom.c:474-507) — every `tcsetattr(2)` of an open port
  (usb_serial.c:1691-1693).

The ucom core adds `usb_pause_mtx(sc->sc_lock, hz/10)` after each callback
(usb_serial.c:777 and :1636), so each cfg task occupies the per-adapter ucom
taskqueue for ~1100 ms against an evil device. `close(2)` is synchronous against
that queue — `ucom_close()` → `ucom_queue_command(ucom_cfg_close)` →
`usb_proc_mwait()` (usb_serial.c:671-672 + 955-957), an uninterruptible wait
(usb_process.c:385-393) — and unplug pins the USB hub event thread the same way
through `ucom_detach()` → `usb_proc_drain()` (usb_serial.c:394). ucycom has NO
`ucom_cfg_close` callback, so close itself issues zero EP0 requests; the damage
is purely the wait behind queued cfg tasks. ucycom is the mildest member of the
cfg-stall family (1 request per task vs. 3–14 for uchcom/uslcom/umoscom/ubsa/
umct/uftdi/uvscom), but the amplification is the same shape: a local user
sustaining a `tcsetattr` loop on the open `/dev/cuaU*` keeps ~1.1 s/task of
uninterruptible occupancy going for as long as the loop runs, and SIGKILL cannot
preempt a closer already inside `usb_proc_mwait`.

## Reproduction (KLD-harness-with-production-code)

No Cypress CY7C64013 device model exists on the guest. The harness compiles the
VERBATIM production code (sed-extracted at build time from the guest's md5-gated
`/usr/src`: `ucycom.c` c7b432ce…, `usb_serial.c` dc5c04db…):

* ucycom.c:62-101+181-182 (softc/constants), :112,117-119 (protos), :299-306,
  :412-444, :446-472, :474-507 — the driver's whole cfg chain;
* usb_serial.c:635-680 (`ucom_queue_command`), :756-780, :906-922, :1619-1637
  (core cfg task wrappers);

and runs it on the REAL `usb_proc_create/msignal/mwait` taskqueue machinery
(the same machinery ucom's cfg callbacks run on), with a real zeroed softc and
`lockinit(…, LK_CANRECURSE)` exactly as ucycom_attach does (ucycom.c:214). The
single interposed symbol is `usbd_do_request_proc` (usb_request.c:760): an
evil-device model that sleeps `timo` ms ("WXFER") and returns
`USB_ERR_TIMEOUT` (silent) or succeeds at `timo-50` (slow-answer), logging each
request's verbatim framing. Task queueing replicates ucom_open's production
shape (usb_serial.c:829-872) and the user's tcsetattr shape (:1690-1693), both
through the verbatim `ucom_queue_command`.

## Measured (run.log, run.2.log — fresh guest, hz=100)

* Phase A (first open + 1 tcsetattr + close; silent device): closer blocked
  **2094 / 2111 ms**, 2 EP0 requests burned (cfg_open + cfg_param tasks; the
  first-open param task no-ops as in production).
* Phase 2 (2 tcsetattrs): 2106 / 2097 ms — the rapid second tcsetattr coalesces
  into the pending `sc_param_task` double-buffer slot (production
  last-wins semantics); a *sustained* loop re-queues as tasks drain, extending
  the occupancy for as long as the attacker keeps looping (~1.1 s per processed
  task; sibling DF-5496 measured the same coalescing with a 5-burst).
* Phase S (device answers at 950 ms — every request SUCCEEDS): **1987 / 1989 ms**.
  This is the ucycom-specific point: with only one request per task, the
  family's "abort the chain on first error" mitigation is a no-op even when the
  device does fail, and covers nothing when it succeeds. The only in-file lever
  is the timeout itself.
* Phase C (fix modeled on a second sed-fixed extraction of the same verbatim
  code, `0, 1000` → `0, UCYCOM_CFG_TIMEOUT(250)`): **638–661 ms**.

## Fix validation

* fix.diff (UCYCOM_CFG_TIMEOUT 250): `git apply --check` clean on the audited
  repo; the patched production ucycom.c (md5 7044be95… built on host, spliced
  byte-identical into the guest tree) compiled `-Werror`-clean, 0 warnings, as
  the real in-tree-style `ucycom.ko` (fix_compile.log, RC=0).
* Behavioral proof at mechanism level: phase C 2094 → 638-661 ms.
* Scope caveat: compile + mechanism level per the family evidence class; no
  physical crafted Earthmate exists on this guest.

## Pass-2 negative results (this file, recorded for weight)

* RX HID framing bounded: 64013 `len = buf[1]` (device, ≤255) and 63743 3-bit
  count are both clamped by `actlen` (ucycom.c:558-559); `actlen ≤ frame len =
  sc_ilen ≤ 1026 = bufsize` (attach clamp ucycom.c:247-254; usb_transfer.c:681).
* TX 2-frame control write bounded by construction: frame0 must be 8 bytes
  (usb_transfer.c:1560-1565) and the data stage ≤ `bufsize - 8` = 1026
  (usb_transfer.c:681,718-726); `sc_olen - offset ≥ 0` since `sc_olen ≥ 2`
  enforced (ucycom.c:248); `usbd_copy_in` walks only allocated pages
  (usb_busdma.c:131-149).
* `sc_temp_cfg[5..31]` sent to the device when `sc_flen > 5` is zero-filled, not
  uninitialized: the newbus softc is `kmalloc(…, M_ZERO)` (subr_bus.c:1953).
  (And the recipient is the attacker's own device.)
* Attach error path (`goto detach` → `ucycom_detach` → `ucom_detach` without
  `ucom_attach` having run) is safe: `ucom_detach` returns immediately unless
  `UCOM_FLAG_ATTACHED` is set (usb_serial.c:371-372).
* `usbd_req_get_hid_desc` M_ZERO's its buffer and passes the device-declared
  length as both alloc size and request length (usb_hid.c:819-835): short
  transfers zero-pad, no uninit read reaches `hid_report_size`.
* `ucycom_pre_param` whitelists speeds 600–57600 (ucycom.c:446-472); B0/0 →
  EINVAL, so `ucycom_cfg_write` never sees a degenerate divisor (the chip takes
  the raw baud word; there is no division in the driver at all).
* The 64013 TX length byte `data[1] = actlen` truncates >255-byte writes
  (protocol misframing only; requires a malicious HID descriptor declaring
  olen > 257 and only misframes the attacker's own device — no host impact).
* Unplug-lifecycle/UAF concerns are DF-5320 (usb_serial.c core), not re-filed.

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