# DF-5759 PoC: rfcomm_ssend violates the pru_send mbuf-ownership contract

## Bug
`sys/netbt/rfcomm_socket.c:426-451`: `rfcomm_ssend()` (the `pru_send`
handler for RFCOMM sockets) takes ownership of the caller's mbuf chain —
the generic `sosend()` clears its `top` pointer unconditionally after
`so_pru_send()` returns (`sys/kern/uipc_socket.c:924-930`; comment at
:1051: "sent or freed in lower layer"), so the handler must consume `m`
on **every** path. `l2cap_ssend` and `sco_ssend` honor this (their `out:`
paths `m_freem(m)`); `rfcomm_ssend` does not:

```c
	m0 = m_copym(m, 0, M_COPYALL, M_NOWAIT);
	if (m0) {
		sbappendstream(&so->so_snd.sb, m);
		error = rfcomm_send(pcb, m0);
	} else {
		error = ENOMEM;          /* <-- m (caller's chain) leaked */
	}
```

When `m_copym(M_NOWAIT)` fails (mbuf pool exhausted), the handler
replies ENOMEM and drops `m` on the floor: a permanent kernel mbuf-chain
leak of the full record being sent.

## Preconditions / reachability
* netbt.ko loaded (admin action). A send on an RFCOMM socket requires
  SS_ISCONNECTED (sosend + PR_CONNREQUIRED), i.e. in normal operation a
  Bluetooth controller and an established session — so from pure
  userland on a headless guest this path is not reachable.
* The defect is in the socket-adapter layer and is exercised
  identically by any caller of so_pru_send(); this pack proves it with a
  production-code KLD rig (`bt_ssend_leak_kld.c`) that drives the REAL
  `so_pru_send` → `rfcomm_ssend` path with a real socket, with **no
  modifications to sys/**.

## Build (in-guest, against /usr/src/sys)
```
make                  # Makefile included in this pack (needs /usr/src/sys)
```

## Run (root)
```
netstat -m | head -1                  # before
kldload /tmp/btssend/btssend.ko       # payload runs at MOD_LOAD
dmesg | grep btssend                  # trace
netstat -m | head -1                  # after: +1025 mbufs (leaked chain)
```

## Expected (stock netbt.ko)
`so_pru_send -> 12 (ENOMEM)` in the dmesg trace and `mbufs in use`
permanently **+1025** (the 1024-mbuf payload chain + pkthdr head), after
the rig has already released its 113k-490k drain mbufs and closed the
socket. Second run: another exact +1025. On the fix.diff-patched
netbt.ko: same ENOMEM, but mbufs stay flat (7 -> 7).