# DF-5488 — uvisor_attach→uvisor_init: up to 2× synchronous 5000 ms-timeout
# EP0 requests on the per-bus USB explore thread; an evil Visor/Palm/Clie
# VID:PID adapter pins bus enumeration for ~5-10 s per insertion

## The chain (production code, executed verbatim in the harness)

`uvisor_attach()` (uvisor.c:302-354) runs on the per-bus USB explore
thread and calls `uvisor_init()` (uvisor.c:326 → 370-517) BEFORE any ucom
port exists, issuing synchronous control requests at the
`USB_DEFAULT_TIMEOUT` of **5000 ms** (usbdi.h:87):

| sc_flag (VID:PID table, uvisor.c:248-278) | requests | uvisor.c | worst |
|---|---|---|---|
| `UVISOR_FLAG_VISOR` (HANDSPRING VISOR 082d:0100) | 1× GET_CONNECTION_INFORMATION vendor IN (wLength 18) | 382-389 | ~5 s |
| `UVISOR_FLAG_PALM4` (Treo, Palm m*/i705/Tungsten/Zire, Clie S360/NX60/TJ37, Garmin, Fossil, AlphaSmart, Tapwave, Samsung) | 1× GET_PALM_INFORMATION vendor IN (wLength 0x44) | 434-442 | ~5 s |
| `UVISOR_FLAG_PALM35` (SONY CLIE_35) | 2× standard requests (UR_GET_CONFIG + UR_GET_INTERFACE) | 476-485, 488-496 | ~10 s |

USB permits a device to NAK a control data stage for the entire 5 s
timeout; an evil adapter (Facedancer/gadget with one of these VID:PIDs)
answering each request just-under-timeout — or never answering — pins the
explore thread (which serializes ALL device enumeration on that bus:
exploration, insertion and removal events) for the full chain, while each
request additionally holds the per-device enum lock (usb_request.c:467).
On timeout the attach fails cleanly (uvisor.c:391-393 etc.), but the stall
has already happened. Same class as DF-5407 (uplcom, 14×5 s ≈ 70 s,
Medium) and DF-5359 (uipaq, ~12.8 s, Low); uvisor's worst case is 2×5 s
(CLIE_35), typical 5 s.

## Evidence class

No Visor/Palm QEMU device model exists — **verbatim-production-extraction
KLD harness** (the DF-5407 evidence class): `build.sh` sed/awk-extracts
the production `uvisor_init()` VERBATIM from the guest's clean
/usr/src/sys/bus/u4b/serial/uvisor.c (defines/structs = lines 85-182 →
uv_defs.h; function = anchor-extracted → uv_init.h; extraction sha256s
recorded in build.log and re-verified reproducible) and only the EP0
entry point it calls (`usbd_do_request_flags`, which `usbd_do_request`
macro-expands to, usbdi.h:511-512) is re-targeted to an evil-device model
(NAK ~4.9 s then answer, USB-legal). Phase B re-extracts from a scratch
copy patched with fix.diff (pure `uvisor_init`→`uvisor_init_fixed` rename).

## Reproduce

```
./build.sh   # verbatim extraction + in-tree kmod build, -Werror clean
./run.sh     # kldload; dmesg | grep HX5488
```

Expected (phase A, evil in-spec-slow answers): VISOR ~4.8 s, PALM4 ~4.8 s,
PALM35 ~9.6 s, all `err=USB_ERR_NORMAL_COMPLETION`.
Expected (phase B, 250 ms driver-side bound): all three ~0.25 s,
`err=USB_ERR_TIMEOUT` (chain aborts).

Observed (two runs): VISOR 4796/4802 ms, PALM4 4794/4803 ms,
PALM35 9591/9609 ms; fixed: 250/265, 259/261, 249/272 ms (run.log,
run.2.log). The request trace (bmRequestType 0xc2/0x80, bRequest
0x03/0x04/0x08/0x0a, wLength 18/68/1/1) matches production exactly; the
PALM4 run also shows device-supplied data flowing through the extracted
code into `config[].endpoint` (10/5 from the 0x5A-filled answer).

## Fix

`fix.diff` bounds the attach-path control timeout to 250 ms
(`UVISOR_INIT_TIMEOUT`, same bound as the uplcom DF-5407 family fix) for
all four call sites. The patched production uvisor.ko compiles -Werror
clean (fix_compile.log).