# DF-5359 VERDICT — untested (rig cannot present the precondition; Low severity per-contract skip)

## Bottom line

The defect is code-certain by arithmetic: `uipaq_attach()` (uipaq.c:1129-1136)
retries a control request 64 times with a 100 ms request timeout and an
unconditional ~100 ms inter-iteration pause, with **no early-out for
"device rejected" or "device gone"**. The loop executes on the per-bus USB
explore thread inside `usb_probe_and_attach()` (usb_device.c:1286-1345, via
`uhub_explore_sub()`), while the device enum lock is held (usb_device.c:1324),
so a crafted device matching any of the ~300 VID:PID pairs in `uipaq_devs[]`
stalls hub-event processing for that bus for ~6.4–12.8 s per insertion,
repeatably via replug. Bounded (no unbounded loop, no memory-safety impact),
hence Low.

## Why untested, honestly

* The project QEMU rig (DF-5320's) attaches a `-device usb-serial` =
  Netchip 0525:7701, which binds **uftdi**, not uipaq (no 0x0525 entries in
  `uipaq_devs[]`, uipaq.c:150-1061).
* QEMU 7.2 on the host exposes **no vendorid/productid override** for any
  attachable USB device model (`-device usb-net,help` and
  `-device usb-storage,help` were queried: no `vendorid` property), so a
  uipaq-matching VID:PID cannot be presented at all.
* No USB host-passthrough hardware (real iPAQ / Facedacer) is available.
* Severity is Low → per the audit contract, Low/Info findings are skipped
  in Phase V; no guest time was spent and the guest was left untouched
  (status `untested`, attempts 0, guest_dirty 0).

## What was runtime-verified (attack-surface existence only, guest was up)

* `/boot/kernel/uipaq.ko` exists on the audit guest; `kldstat` shows it is
  not loaded until a matching device appears (module auto-load path via
  uhub/devd), i.e. the attack surface is real on a stock system the moment
  a crafted device is plugged in.

## Fix validation

Not performed (nothing to compare against without the precondition device).
`fix.diff` is authored from the line-level understanding: retry only while
the error is `USB_ERR_TIMEOUT` (the genuine "device not ready yet" case),
break immediately on success/stall/gone, and cap iterations at 16 so the
worst case drops from ~12.8 s to ~3.2 s. fix_status = not_tested.

## Kernel references

* sys/bus/u4b/serial/uipaq.c:1124-1136 (the loop)
* sys/bus/u4b/serial/uipaq.c:150-1061 (VID:PID match table)
* sys/bus/u4b/usb_device.c:1286-1345 (usb_probe_and_attach caller context)
* sys/bus/u4b/usb_device.c:1324 (enum lock held across attach)
* sys/bus/u4b/usb_hub.c:995-1090 (uhub_explore serialization)

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