# DF-1106 — Unbounded XHCI extended-capability pointer walk

## Claim
`xhci_pci_take_controller()` at `sys/bus/u4b/controller/xhci_pci.c:398-413`:

```c
for (eecp = XHCI_HCS0_XECP(cparams) << 2;            /* line 398 */
     eecp != 0 && XHCI_XECP_NEXT(eec);                /* line 399 */
     eecp += XHCI_XECP_NEXT(eec) << 2) {              /* line 400 */
    eec = XREAD4(sc, capa, eecp);                      /* line 401 — OOB read */
    if (XHCI_XECP_ID(eec) != XHCI_ID_USB_LEGACY)
        continue;
    bios_sem = XREAD1(sc, capa, eecp + XHCI_XECP_BIOS_SEM);  /* line 405 — OOB */
    ...
    XWRITE1(sc, capa, eecp + XHCI_XECP_OS_SEM, 1);            /* line 410 — OOB write */
    ...
}
```

- `XHCI_HCS0_XECP` is a 16-bit field (xhcireg.h:70) → initial `eecp` can be
  up to `0xFFFF << 2 = 262140` bytes, larger than typical XHCI BARs (8-64 KB).
- `XHCI_XECP_NEXT` is an 8-bit field (xhcireg.h:192) → grows `eecp` by up to
  `0xFF << 2 = 1020` bytes per iteration, with no termination other than
  reading a 0 from the controller.
- `XREAD4`/`XREAD1`/`XWRITE1` (xhcireg.h:205-222) expand to plain
  `bus_space_read/write_*` with **no bounds check against `sc->sc_io_size`**
  (which IS recorded at xhci_pci.c:206 but never consulted in this file).

A malicious PCI XHCI controller (Thunderbolt / ExpressCard / PCIe hot-plug)
can:
- Supply an `eecp` pointing past its BAR → on platforms with precise
  `pmap_mapdev` bounds this is a kernel page fault panic.
- Return `NEXT=0xFF` from an OOB read (returns `0xFFFFFFFF`) → loops
  unboundedly with growing `eecp` until fault (DoS).
- Make the kernel perform an OOB MMIO **write** at line 410
  (`XWRITE1(sc, capa, eecp + XHCI_XECP_OS_SEM, 1)`).

Same class as DF-1092 (EHCI).

## Reproducibility on this guest
The default audit guest exposes **no XHCI controller** to the kernel.
QEMU is launched with `-device virtio-net-pci` and no USB controller; the
kernel boots without attaching `xhci0`. `pciconf -lv | grep -i xhci` is
empty and `dmesg | grep -iE 'xhci|usb'` shows no XHCI attach.

The XHCI driver is built into the GENERIC kernel, but `xhci_pci_attach`
(and thus `xhci_pci_take_controller`) is never called without an XHCI PCI
device. The bug is **latent** — confirmed by source trace, not
runtime-triggerable on this guest. QEMU *can* emulate an XHCI controller
(`-device qemu-xhci`), but adding one would require modifying the vm.sh
QEMU command (guest-facing PCI topology change), and the bug is
fundamentally a malicious-controller scenario where the controller lies
about its capability registers — QEMU's emulated XHCI reports honest
values, so even with `-device qemu-xhci` the bounds check would never
trigger.

## Fix
`fix.diff`: bound `eecp + 4` against `sc->sc_io_size` in the loop
condition so any pointer past the mapped BAR terminates the walk.