DF-5742 — hci_mtap() taps into receive buffers with no flow control:

unbounded mbuf accumulation -> global mbuf-pool exhaustion (kernel-wide allocation failure / hard hang)

Production code: sys/netbt/hci_socket.c:1003-1010

m0 = m_copym(m, 0, M_COPYALL, M_NOWAIT);
if (m0 && sbappendaddr(&pcb->hp_socket->so_rcv.sb, &sa, m0, ctlmsg))
        sorwakeup(pcb->hp_socket);

sbappendaddr() checks no high-water mark; ssb_cc/ssb_mbcnt grow without bound for a socket that never reads. Every HCI packet (event, command, ACL, SCO) that passes a tap socket's filters is copied into its receive queue. A raw HCI socket that stops reading (or a handful of them) turns the Bluetooth stack into an unbounded consumer of the GLOBAL mbuf pool: every kernel allocation needing an mbuf pkthdr fails system-wide (network, VM paging paths, ...), observed live as "Warning: objcache(mbuf pkthdr) exhausted" on ALL CPUs followed by an unrecoverable hard hang of the whole guest (exhaustion.txt, race4.log, race5.log).

Reachability: raw HCI sockets are unprivileged; on this kernel every socket is even HCI_PRIVILEGED (DF-5741), so an unprivileged user can (1) open N promiscuous sockets with full packet+event filters via setsockopt and simply never read, and (2) generate the traffic himself (sending commands produces Command Complete/Status events that are tapped). No controller traffic from other users needed; no race; no timing.

The evidence in this pack was recorded during the DF-5740 race rig iterations whose taps were not draining (the first crash investigation, before the taps were made to drain, was in fact CAUSED by this bug, not by the DF-5740 race - see DF-5740/panic.txt's confound note; both point at the same run family).

Reproduce

Load the DF-5740 rig, sysctl hw.hsh_setup=1, then run its trigger with taps that never read, e.g. ./trigger 100 48 40 (taps are only drained at the end) while sysctl hw.hsh_fire=99999 floods completions. Expected: exhaustion warnings on all CPUs within tens of seconds, then system-wide allocation failure/hang.

Fix (proposed, NOT runtime-validated separately)

fix.diff: skip sockets whose receive buffer has no space (ssb_space() check before sbappendaddr), mirroring what every other tap/protocol does. Authored after the mechanism was confirmed; not separately rebuilt on the guest (the class is resource exhaustion, not memory corruption), so mark untested.

DF-5742 — VERDICT

Reproduced: yes (as part of the DF-5740 rig runs; the exhaustion is attributable to this bug, not to the race): with non-draining promiscuous tap sockets and controller-traffic injection through production hci_input_event/hci_output_cmd paths, the guest printed "Warning: objcache(mbuf pkthdr) exhausted" on cpu0..cpu3 and then hung hard (no trap, no dump, no console output, ssh dead) — twice (race4, race5; exhaustion.txt). Each copy is m_copym + sbappendaddr with zero bound (hci_socket.c:1003-1005); ssb_cc grows forever; the mbuf pool is global.

Impact: local DoS, kernel-wide (all mbuf-pkthdr allocations fail; hard hang observed). Unprivileged (HCI sockets are unprivileged; DF-5741 makes the full tap reachable by any user trivially; even without it, default filters pass Command Complete/Status events that the attacker's own sends generate).

Fix: proposed in fix.diff (ssb_space gate before sbappendaddr); mechanism-confirmed but not separately rebuilt/validated on the guest (resource-exhaustion class; the fix is the standard tap pattern).

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.