DF-5282 — EHCI unvalidated register geometry (sc_offs / sc_noport)

What

ehci_init() latches the device-reported register geometry with no validation:

• sys/bus/u4b/controller/ehci.c:308 — sc->sc_offs = EHCI_CAPLENGTH(...) (8-bit, device MMIO)
• sys/bus/u4b/controller/ehci.c:327 — sc->sc_noport = EHCI_HCS_N_PORTS(...) (4-bit, device MMIO)

sc->sc_io_size (BAR size, ehci_pci.c:324) is never consulted. Every subsequent EOREAD4/EOWRITE4 (ehci.h:372-383) adds sc_offs to the register offset raw. Furthest reach: 0xFF + EHCI_PORTSC(15) = 0x17F bytes past the BAR base. With an adversarially undersized BAR (< 0x180 — also device-controlled) every port-register access is out-of-bounds MMIO read/write (DF-5268 class, bounded variant). Same defect family as DF-5268/DF-2336/DF-1106 (xHCI).

Guest environment

• DragonFly 6.5-DEVELOPMENT x86_64 (QEMU/KVM, QEMU 7.2), ICH4-style usb-ehci device: BAR 0x1000 @ 0xfebd1000, CAPLENGTH=0x20, 6 ports.
• ehci is a KLD module (/boot/kernel/ehci.ko).

Build

# in guest (needs /usr/src + /usr/obj kernel build dir):
mkdir -p /root/ehcipwn && cp poison.c Makefile /root/ehcipwn/
cd /root/ehcipwn && make KERNBUILDDIR=/usr/obj/usr/src/sys/X86_64_GENERIC

Run (A/B demonstration — read/write path geometry confusion)

./baseline.sh          # roothub GET_STATUS / SET+CLEAR SUSPEND roundtrip
kldload /root/ehcipwn/ehcipwn.ko     # latches sc_offs=0xFF (== malicious CAPLENGTH)
./poisoned.sh          # same requests now hit io_hdl+0x147/0x15B
kldunload ehcipwn

Expected: baseline port status 0x0504 (POWER|HIGH|SUSPEND) / 0x0500; poisoned GET_STATUS returns 0x0400 (POWER bit lost — wrong register read); poisoned SET_SUSPEND "succeeds" but the real PORTSC is untouched (0x0500 after restore).

Run (hard live-lock — interrupt path)

kldload /root/ehcipwn/ehcipwn.ko
# QEMU monitor: device_add usb-kbd,id=k1,bus=ehci0.0,port=1

Expected (unpatched kernel): the first port-change interrupt is read via the poisoned offset (returns 0), the handler exits without acking the real USBSTS.PCD, the level-triggered INTx re-fires forever -> the guest live-locks: ssh dies within ~20 s, serial console silent, qemu spins at 40-85% CPU, vm.sh status => down. Reproduced 3/3 from clean snapshots (2 baseline + 1 patched-module kernel). Control run (identical hotplug, no poison): ukbd0 attaches, guest healthy.

Fix

fix.diff — init-time geometry validation in ehci_init() before any sc_offs-relative access. Rejects hostile CAPLENGTH/N_PORTS combinations against sc_io_size (closes the from-boot malicious-geometry latching and the undersized-BAR OOB). No-regression verified on the patched module (real EHCI passes, full USB function incl. hotplug). The reject branch cannot be exercised on QEMU (its EHCI model hardcodes CAPLENGTH=0x20 / BAR=0x1000); the post-init corruption vector is equivalent to a device storming its own IRQ line — see VERDICT.md.

DF-5282 — VERDICT

Status: reproduced (impact: dos — system-wide hard live-lock); memory-safety facet (OOB MMIO) is code-certain but bounded and could not be manifested on this guest (hard blocker: QEMU's EHCI model hardcodes a 4 KB BAR). Confidence: certain.

Root cause

ehci_init() (sys/bus/u4b/controller/ehci.c:308,327) latches two device-controlled MMIO values with no validation against the mapped resource size:

sc->sc_offs   = EHCI_CAPLENGTH(EREAD4(sc, EHCI_CAPLEN_HCIVERSION)); /* 8 bits */
sc->sc_noport = EHCI_HCS_N_PORTS(sparams);                          /* 4 bits */

Every later register access is bus_space_{read,write}_4(io_hdl, sc->sc_offs + reg) (ehci.h:372-383). sc->sc_io_size (stored by the glue at ehci_pci.c:324) is never consulted anywhere in the driver. The furthest register touched is EHCI_PORTSC(sc_noport) = 0x44 + 4*noport (ehci.c:2068 root-intr scan; ehci.c:3251,3345,3395 roothub requests; ehcireg.h:139), so the driver's whole access window is [sc_offs, sc_offs + 0x44 + 4*sc_noport] ⊆ [0, 0x17F]. A malicious or broken controller that reports CAPLENGTH=0xFF (and, for the OOB to materialize, a BAR smaller than 0x180 — both fully device-controlled) turns every port-register access into an out-of-bounds MMIO read/write of up to (0x17F − bar_size) bytes past the mapping — the EHCI member of the xHCI register-geometry family (DF-5268 CAPLENGTH/DBOFF/RTSOFF, DF-2336/DF-1106 XECP walk). Because CAPLENGTH is 8 bits here, the EHCI variant's reach is bounded to 383 bytes, unlike xHCI's unbounded 32-bit offsets.

Verification methodology (DF-5268 pattern)

QEMU's EHCI hardcodes sane register values, so the malicious latched value was injected via a KLD (poison.c) that walks devclass "ehci" → softc and stores 0xFF into the already-latched sc->sc_offs — bit identical to what ehci_init() would have stored from a CAPLENGTH register reading 0xFF. Everything downstream is the driver's unmodified code. Guest: DragonFly 6.5-DEVELOPMENT x86_64, QEMU 7.2 ICH4-style usb-ehci (8086:24cd), BAR 0xfebd1000–0xfebd1fff (0x1000), CAPLENGTH 0x20, 6 ports, ehci as /boot/kernel/ehci.ko.

Observed results

1. Read path consumes the unvalidated offset — roothub GET_STATUS(port) (ehci.c:3345) returns real status 0x0500 (POWER|HIGH_SPEED) with sane geometry; with sc_offs=0xFF the same request returns 0x0400 (the POWER bit from EHCI_PS_PP is gone) because EOREAD4 now reads io_hdl+0x147/0x15B (unimplemented in-bar).
2. Write path consumes the unvalidated offset — baseline SET_FEATURE(UHF_PORT_SUSPEND) (ehci.c:3402, EOWRITE4) makes the SUSPEND bit visible (0x0504); the identical request with the poison loaded returns OK but, after restoring sc_offs, the real PORTSC shows 0x0500 — no SUSPEND — proving the kernel MMIO write landed at the wrong offset (io_hdl+0x147) and never reached the port register.
3. Interrupt path → hard system live-lock — with sc_offs=0xFF loaded and the PCD re-enabled by ehci_pcd_enable (ehci.c:1429-1441, itself writing USBINTR/USBSTS via the poisoned offset), a single USB device hotplug (QEMU monitor device_add usb-kbd) wedges the whole machine: ehci_interrupt() (ehci.c:1504-1513) reads USBSTS via the poisoned offset → 0 → exits without acking the real USBSTS.PCD → the level-triggered INTx re-fires forever. ssh dies within ~20 s, the serial console prints nothing further (no panic — pure live-lock), the qemu process spins at 40–85% CPU, vm.sh status ⇒ down. Reproduced 3/3 from clean with-src snapshots (2× unpatched, 1× with the fix module loaded). Control run (identical hotplug, no poison): ukbd0 attaches and the guest stays healthy.

The OOB facet — why it did not manifest here (hard blocker)

Max poisoned offset = 0xFF + 0x44 + 415 = 0x17F (383). QEMU's EHCI MMIO region is 0x1000 bytes (device model constant; verified via the monitor BAR listing and sc_io_size=0x1000 printed by the KLD), so every poisoned access stays inside the mapping — no page fault, no adjacent MMIO corruption is possible* on this guest. Manifesting the OOB requires an adversarially undersized BAR (< 0x180), which QEMU's usb-ehci device model cannot be configured to expose. On real malicious hardware the same driver code performs the accesses past the mapping (bounded 0x17F window): driver-controlled dword writes with device-influenced values at 15 selectable 4-byte slots (EHCI_PORTSC(1..15)), plus reads. Adjacent PCI device registers mapped within 383 bytes after such a BAR are corruptible.

Attribution of the live-lock

The wedge requires the geometry to become adversarial after the controller was initialized and real interrupts enabled (the KLD simulates mid-life corruption / re-negotiation, or a from-boot malicious device would have real USBINTR never written). A device that can flip its CAPLENGTH mid-life could also simply assert INTx forever — an IRQ storm no driver fix can prevent. The driver-controllable defect is the unvalidated latch itself plus the resulting blind/mute interrupt handling and geometry confusion (items 1–3 above); the fix below closes the latch-time vector.

Fix (fix.diff, authored post-verification; never applied to sys/)

Init-time validation in ehci_init() immediately after both values are latched and before the first sc_offs-relative access (ehci_hcreset at ehci.c:335): reject sc_offs < 0x08 or sc_offs + 0x44 + 4*sc_noport > sc_io_size with USB_ERR_IOERROR.

Validation performed: - Patch applied cleanly to the guest's /usr/src; quickkernel + installkernel rebuilt ehci.ko containing the guard (string verified in the installed module; auto-loaded at boot). - No regression (pass-branch): patched module boots the real QEMU EHCI (offs=0x20, noport=6, io_size=0x1000 → passes), full USB function including device enumeration. - Reject-branch: not exercisable on this guest (QEMU EHCI hardcodes CAPLENGTH=0x20 / BAR=0x1000) — fix_status not_testable for that branch. - Wedge re-run on the patched kernel: the post-init corruption trigger still wedges the guest (expected — init-time validation cannot cover an offset that flips after init; documented above). This vector is attributed to generic malicious-device IRQ storming.

Threat model

Malicious / compromised EHCI silicon or emulated controller (AV:P), or a config-space/caps-corrupted device. Not reachable by an unprivileged local user through this file (no ioctls here; /dev/usb nodes are operator/root). Consequences: (a) deterministic USB-subsystem misbehavior/hard machine live-lock from a single device plug, (b) bounded OOB MMIO read/write on adversarially-undersized-BAR hardware.

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.