VERDICT — DF-5287

Status: REPRODUCED (unprivileged local user, fresh-boot guest, no kernel modifications) — reproduced, impact dos (kernel memory leak + permanent endpoint lockout; same race also opens an unlocked usb_fifo_free_buffer() UAF window, documented below).

How it was reproduced

Guest: DragonFly 6.5-DEVELOPMENT (with-src snapshot), QEMU x86_64, -device usb-ehci + -device usb-mouse (ugen0.2, interrupt-IN endpoint node /dev/usb/0.2.1). Unprivileged user maxx (uid 1001, member of operator, nodes chmod 0660 — the standard BSD "libusb user" configuration; default DragonFly ships these nodes 0600 root:operator).

1. Baseline: vmstat -m → USB 16 allocs / 19.8K.
2. ./df5287 3000 — two threads race read() on one shared O_RDONLY|O_NONBLOCK fd, close+reopen per iteration.
3. After 2938 iterations the PoC printed its marker: EIO after 2938 iterations (endpoint refcount_alloc exhausted by orphaned usb_xfers -- double-setup race won >= 61 times).
4. vmstat -m → USB 331 allocs / 1.10M (2.95K requests): ~1 MB of never-freeable kernel memory accumulated from the orphaned xfer blocks.
5. Re-running the PoC immediately EIOs at iteration 0 — the endpoint stays dead (refcount_alloc pinned at USB_EP_REF_MAX) until the device is re-plugged; usbconfig dump_info still shows a healthy device, so this is a silent lockout of the endpoint for every consumer, kernel drivers included.
6. Write-side variant (df5287c, usb-storage bulk-OUT endpoint 0.2.2, umass not attached): same leak signature — M_USB grew 34.3K → 1.24M within ~1000 iterations before the run was stopped (log run.3.log).

Why the leak is permanent

Each race-won iteration leaves one usbd_transfer_setup() allocation unreferenced:

• usbd_transfer_setup() incremented xfer->endpoint->refcount_alloc (sys/bus/u4b/usb_transfer.c:1121) and info->setup_refcount (usb_transfer.c:1132);
• the second setup's entry loop wrote ppxfer[n] = NULL over the first setup's pointers (usb_transfer.c:935 — ppxfer[n] = NULL; in the initial sanity loop), so usbd_transfer_unsetup() never sees them again;
• therefore neither refcount_alloc-- (usb_transfer.c:1421) nor info->setup_refcount-- (usb_transfer.c:1431) ever runs for the orphan, and the memory block is never freed.

The UAF window (same root cause, harder to time)

ugen_transfer_setup() calls usb_fifo_alloc_buffer() -> usb_fifo_free_buffer() (sys/bus/u4b/usb_dev.c:2009-2020) after re-acquiring... actually before re-acquiring priv_lock (usb_generic.c:145-166 in the unfixed tree: the buffer swap sits between lockmgr(f->priv_lock, LK_RELEASE) and the final lockmgr(f->priv_lock, LK_EXCLUSIVE)). usb_fifo_free_buffer() does kfree(f->queue_data) + memset of both queues with no lock at all, while the winning setup's live callbacks (ugen_ctrl_read_callback -> usb_fifo_put_data(), usb_dev.c:2064; ugen_ctrl_write_callback -> usb_fifo_get_data(), usb_dev.c:2176) iterate those queues under priv_lock. A racing second setup therefore frees the mbuf storage under a running callback: writes into freed M_USBDEV heap + corrupted queue linkage feeding read()/write(). This window was not converted into a demonstrated panic within the time budget (it needs a callback in flight inside a ~µs-wide free window; the mouse endpoint provides no traffic in a headless QEMU and the storage write-path was used for the leak runs), but it follows directly from the same unlocked code path. The fix removes it.

Fix validation

See fix_validation.md / fix_build.log / run.patched.log — with fix.diff (busy-flag in ugen_transfer_setup() + fifo buffer swap under priv_lock) applied to a rebuilt kernel, the exact same PoC ran to completion without the EIO marker and without M_USB growth.

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.

Fix validation — DF-5287 (combined kernel with DF-5288 fix)

Baseline (unpatched with-src kernel)

Patched kernel (fix.diff: flag_setup_busy guard in

ugen_transfer_setup() + fifo buffer swap under priv_lock)

Kernel: same validated build as DF-5288 (#1: Fri Oct 2 05:05:50 UTC 2026, BUILD_RC=0/INSTALL_RC=0).