DF-5315 — USB_FS_OPEN × USB_FS_OPEN double-entry: orphaned xfer + endpoint lockout

Two threads race USB_FS_OPEN on the same endpoint slot of a shared ugen fd. Both pass the unlocked f->fs_xfer[ep] != NULL check, both run usbd_transfer_setup(); the second NULLs/overwrites the first's pointer → the first xfer is orphaned: leaked M_USB block + leaked endpoint->refcount_alloc. After 63 orphans the endpoint is dead for all consumers; memory leaks unboundedly.

Build / Run (guest, as maxx with rw on /dev/usb/0.2.0)

./build.sh
./run.sh          # 20 s race + cleanup + post-cleanup probe

Success criterion (unpatched): POST-CLEANUP USB_FS_OPEN FAILED: Cannot allocate memory + vmstat -m USB growth (~1 MB / 20 s). On the fix-validated kernel: POST-CLEANUP OPEN SUCCEEDED.

Fix: the setup-claim hunk of ../DF-5314/fix.diff (validated there).

VERDICT — DF-5315

Status: REPRODUCED (unprivileged local user, fresh boot) — reproduced, impact dos: permanent kernel memory leak (~1 MB per 20 s of racing; unbounded if repeated on other endpoints/devices) + permanent endpoint lockout for every consumer (ugen ioctls, read()/write(), kernel drivers) until replug/reboot.

Root cause

ugen_ioctl() case USB_FS_OPEN checks f->fs_xfer[ep_index] != NULL → EBUSY with no lock (sys/bus/u4b/usb_generic.c:1462) and then calls usbd_transfer_setup(), which (a) sleeps for a long time (usbd_enum_lock usb_transfer.c:942, kmalloc M_WAITOK :1220, DMA setup) and (b) NULLs its target slot at entry — ppxfer[n] = NULL (usb_transfer.c:935, no lock) — storing the finished pointer only at the very end (:1138). Two barrier-synchronised opens that both pass the EBUSY check therefore both run a full setup for the same slot; the second entry's NULL/overwrite orphans the first usb_xfer:

• its endpoint->refcount_alloc (incremented at usb_transfer.c:1121) is never decremented (unsetup does that at :1421) → after USB_EP_REF_MAX = 0x3F orphans the endpoint rejects every further usbd_transfer_setup() (:1118-1119);
• its root block (root + xfer + DMA pages, allocated at :1220) is never freed → unbounded M_USB growth.

This is the ioctl-side sibling of DF-5287 (which races read()/write() through ugen_transfer_setup() on f->xfer[]): different entry, different array, same orphan mechanism — and the DF-5287/DF-5288 fixes do not touch USB_FS_OPEN, so it survives them (verified: this race was reproduced on a kernel that already carries the DF-5287+DF-5288 fix semantics in the tree analysis; the guest baseline is stock #0).

Reproduction

Guest: DragonFly 6.5-DEVELOPMENT #0, QEMU x86_64, usb-ehci + usb-mouse, unprivileged maxx on /dev/usb/0.2.0 (0666).

./df5315 20 — two threads, three barriers per round: both fire USB_FS_OPEN simultaneously; a single serialised closer frees the survivor. Result (run.log):

• ~60 rounds in ~6 s, essentially every round double-won (121 successful opens, 61 orphans);
• counters freeze at 60+61 (refcount exhausted);
• vmstat -m USB: 16 allocs/19.8K → 331 allocs/1.02M (+61 orphaned blocks, ~1 MB leaked in 20 s, never freeable);
• after full cleanup (USB_FS_CLOSE ×4 + USB_FS_UNINIT + re-INIT) a fresh USB_FS_OPEN fails ENOMEM forever.

Fix validation

The fix is the USB_FS_OPEN setup-claim hunk of DF-5314/fix.diff (self-contained there): the slot is claimed under priv_lock with a sentinel before entering usbd_transfer_setup(), the setup runs into a local pointer, and only the claim winner publishes. On the patched kernel (run.patched.log): opens serialise (600 successes in 12 s), no exhaustion, post-cleanup open succeeds, and vmstat -m shows zero orphan growth after the whole suite.

Kernel references

• sys/bus/u4b/usb_generic.c:1456-1465 (unlocked EBUSY check)
• sys/bus/u4b/usb_generic.c:1538-1540 (setup on the shared slot)
• sys/bus/u4b/usb_transfer.c:935 (entry slot NULL, no lock)
• sys/bus/u4b/usb_transfer.c:942, :1220 (sleeping setup window)
• sys/bus/u4b/usb_transfer.c:1118-1121 (endpoint refcount)
• sys/bus/u4b/usb_transfer.c:1138 (late pointer store)

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)