# DF-5757 PoC: l2cap_ctloutput PRCO_GETOPT success-path mbuf leak

## Bug
`sys/netbt/l2cap_socket.c:119-132`: in `l2cap_ctloutput()`, the
`PRCO_GETOPT` case allocates an mbuf with `m_get(M_NOWAIT, MT_DATA)`
(:120), fills it via `l2cap_getopt()` (:125), and copies the result to
userspace with `soopt_from_kbuf()` (:131) — but only the `m->m_len == 0`
error path (:126-130) ever frees the mbuf. On every successful
`getsockopt(2)` the mbuf is leaked: exactly 1 mbuf per call.

For a valid option (`SO_L2CAP_IMTU`, `SO_L2CAP_OMTU`, `SO_L2CAP_FLUSH`,
`SO_L2CAP_LM`, `SO_L2CAP_IQOS/OQOS`) `l2cap_getopt()`
(`sys/netbt/l2cap_upper.c:521-555`) returns a non-zero length, so the
success path is taken on every call.

This is the l2cap sibling of DF-0709 (sco_socket.c, same defect shape).
The pass-1 finding DF-0682 covers only the `m == NULL` argument-evaluation
panic on the *error* path of this same block; the success-path leak was
not filed.

## Preconditions
* Bluetooth stack loaded: `kldload netbt.ko` (admin action; netbt is
  `optional bluetooth`, not in X86_64_GENERIC — sys/conf/files:1613).
* Then ANY local unprivileged user. No Bluetooth controller needed: the
  socket and its pcb exist right after `socket(2)`; `l2cap_ctloutput`
  only needs `so->so_pcb != NULL` (:108).

## Build
```
cc -o bt_getopt_leak bt_getopt_leak.c
```

## Run
```
./bt_getopt_leak 10000 0        # l2cap only
netstat -m | head -1            # before/after comparison (see run.sh)
```

## Expected
`mbufs in use` climbs by exactly 1 per successful call
(7 -> 10007 after 10000 calls on the stock netbt.ko). Pool max is
146632 mbufs on this guest, so ~146k calls exhaust the kernel mbuf pool
and every network allocation in the system fails (permanent, the leaked
mbufs are never freed). On the patched module (fix.diff) the count stays
flat and getsockopt still returns correct data (mtu=672, len=2).