# 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.