DF-5531 — VERDICT

Status: reproduced (behavioral/performance; no memory-safety impact).

Environment

Same guest as DF-5530 (DragonFly 6.5-DEVELOPMENT, bpf compiled in, qemu-xhci). tap_cost.c KLD calls the production usbpf_xfertap() (global symbol, sys/bus/u4b/usb_pf.c:345) with a synthetic 8x512 BULK-OUT xfer whose xroot->bus points at the real usbus0 softc, after ifconfig usbus0 create with no bpf listener attached.

Result (two runs, two independent boots)

run 1: (A) ifp set, if_bpf==NULL : 1094 cycles/call   (B) ifp NULL:   25   -> 43.5x
run 2: (A) ifp set, if_bpf==NULL : 1256 cycles/call   (B) ifp NULL:   34   -> 36.2x

run.log prints bus ifp=0xfffff8008fd1e480 if_bpf=0 — live proof that DragonFly's bpf leaves ifp->if_bpf NULL until a listener attaches (net/bpf.c:297/324). Case (A) therefore measures exactly the created-but-unwatched state: full precompute + kmalloc(totlen) (usb_pf.c:381) + usbd_copy_out of all 4096 payload bytes (usb_pf.c:468) + bpf_tap(NULL,…) no-op (net/bpf.c:1245) + kfree (usb_pf.c:490). Case (B) is the only early-out that remains (usb_pf.c:362).

The ~36-44x multiplier scales with payload: for real controllers this runs per transfer, under the USB BUS lock on the SUBMIT paths (usb_transfer.c:2630/2813), for as long as a root-created usbus clone exists with no listener — a standing availability tax on every device on that bus (isochronous/webcam-class traffic being the worst case).

Impact ceiling

Availability/performance only (root-armed), no corruption, no leak, no privilege boundary crossed — hence Info severity. Memory safety is intact: bpf_tap is NULL-safe (net/bpf.c:1245-1248) and the tap buffer is fully initialized (headers at usb_pf.c:387-419, zero-pad at usb_pf.c:475-476).

Fix

fix.diff: add if (bus->ifp->if_bpf == NULL) return; after the existing bus->ifp == NULL check (usb_pf.c:362), i.e. restore FreeBSD's early-out with DragonFly-appropriate plumbing. Info-severity finding; fix validation is code-inspection only (behavior is proven, the one-line guard obviously short-circuits case (A) — no kernel rebuild performed for this Info finding; the DF-5530 rebuild in the same session boots and behaves normally with DF-5531's line present in the tree? No — DF-5531's fix was NOT part of the DF-5530 fix kernel; marked fix_status=not_testable accordingly).

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.