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):

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

DF-5488 VERDICT — REPRODUCED (verbatim production code)

Finding: uvisor_attach() → uvisor_init() (uvisor.c:326, 370-517) issues up to two synchronous EP0 control requests at the 5000 ms USB_DEFAULT_TIMEOUT (usbdi.h:87) on the per-bus USB explore thread, before the ucom port exists: 1× vendor IN for VISOR devices (uvisor.c:382-389), 1× vendor IN for PALM4 devices (uvisor.c:434-442), 2× standard requests for PALM35 devices (uvisor.c:476-496). An evil adapter with one of the 28 VID:PIDs in uvisor_devs[] (uvisor.c:248-278) that NAKs the data stages pins bus-wide enumeration for the full chain (~5 s typical, ~10 s for CLIE_35), holding the per-device enum lock (usb_request.c:467) per request. Same class as DF-5407 (uplcom ~70 s, Medium) / DF-5359 (uipaq ~12.8 s, Low).

Reproduction (verbatim-production-extraction harness, DF-5407 class)

The production uvisor_init() is extracted VERBATIM from the guest's clean tree and compiled into the harness KLD; only the EP0 entry point it calls is re-targeted to an evil-device model (NAK ~4.9 s → answer, USB-legal; this is the worst case because the chain then continues to the next request). Guest and audited host tree are identical (uvisor.c sha256 b742032f0dab0dc9c5cbfd63432834c00828390ddfe97f3410298f d703844438). Extraction itself is reproducible (sha256s re-recorded post-run and matching build.log: uv_defs.h 7911b455…, uv_init.h 63a03e13…).

Measured (hz=100 guest, two runs each):

Decisive lines (run.log / run.2.log): HX5488: PALM35 (Sony Clie 3.5): uvisor_init() DONE err=USB_ERR_NORMAL_COMPLETION ELAPSED=9591 ms HX5488: VISOR … ELAPSED=4796 ms, HX5488: PALM4 … ELAPSED=4794 ms Full EP0 trace confirms the exact production requests: bmRequestType=0xc2 bRequest=0x03 wLength=18 (GET_CONNECTION_INFORMATION), bmRequestType=0xc2 bRequest=0x04 wLength=68 (GET_PALM_INFORMATION), bmRequestType=0x80 bRequest=0x08 wLength=1 (UR_GET_CONFIG) + bRequest=0x0a (UR_GET_INTERFACE). The PALM4 run additionally shows the device-supplied endpoint bytes flowing through the verbatim code into config[].endpoint (cfg endpoints 10/5 from the 0x5A-filled response).

Why this is the production behavior

• uvisor_attach() calls uvisor_init(sc, uaa->device, uvisor_config_copy) at uvisor.c:326 before ucom_attach; attach runs on the per-bus explore thread (established family-proven in DF-5407/DF-5359: usb_needs_explore → usb_bus_explore → device attach serializes the bus).
• Each request is usbd_do_request_flags(..., USB_DEFAULT_TIMEOUT) / usbd_do_request(...) (macro → same, usbdi.h:511-512), whose "WXFER" wait loop sleeps until completion or timeout (usb_request.c:642-644, 699-704). A NAK-ing device burns the full 5000 ms per request.
• On timeout, err aborts the chain (uvisor.c:391-393, 444-446, 483-485, 494-496) and attach fails — but the multi-second explore-thread stall has already happened; a gadget device can also answer at 4.9 s to keep the chain going (modeled in phase A).

Severity

Low — bounded (~5-10 s per insertion), requires an evil/malfunctioning Visor-family adapter; family precedent (DF-5359 at ~12.8 s = Low, DF-5407 at ~70 s = Medium). Impact: bus enumeration latency / hub event thread stall, no corruption, no leak.

Fix validation

fix.diff adds UVISOR_INIT_TIMEOUT (250 ms) and uses it at all four call sites (vendor coninfo, palm info, GET_CONFIG, GET_INTERFACE). Validated two ways: 1. Harness phase B re-extracts the patched function verbatim (renamed): all three variants collapse to ~250 ms with USB_ERR_TIMEOUT and a clean chain abort. 2. The fully patched production uvisor.c compiled -Werror clean as a kmod on the guest (fix_compile.log, RC=0).

Negative results / what was checked and killed

• PALM4 short-transfer uninit: the actlen < 12 check (uvisor.c:447-451) covers exactly the bytes later consumed (offsets 1, 8, 9 of uvisor_palm_connection_info), so no uninitialized read on that path (the unguarded sibling is the VISOR path → DF-5489).
• Device-supplied endpoint nibbles (uvisor.c:452-460) only feed usbd_transfer_setup endpoint matching (uvisor.c:333-335), which validates type/direction against the real interface descriptors.
• Guest left clean: harness dirs removed, production uvisor.c untouched.

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.