# DF-5758 PoC: rfcomm_ctloutput PRCO_GETOPT success-path mbuf leak

## Bug
`sys/netbt/rfcomm_socket.c:116-127`: in `rfcomm_ctloutput()`, the
`PRCO_GETOPT` case allocates an mbuf with `m_get(M_WAITOK, MT_DATA)`
(:117), fills it via `rfcomm_getopt()` between `crit_enter()/crit_exit()`
(:118-120), and copies the result to userspace with `soopt_from_kbuf()`
(:126) — but only the `m->m_len == 0` error path (:121-125) ever frees
the mbuf. Every successful `getsockopt(2)` leaks exactly 1 mbuf.

For a valid option (`SO_RFCOMM_MTU`, `SO_RFCOMM_LM`, `SO_RFCOMM_FC_INFO`)
`rfcomm_getopt()` (`sys/netbt/rfcomm_upper.c:535-567`) returns a non-zero
length, so the success path is taken on every call.

This is the rfcomm sibling of DF-0709 (sco_socket.c) and DF-5757
(l2cap_socket.c). Pass-1 finding DF-0680 covers only the `m == NULL`
argument-evaluation panic on the *error* path; 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).
* Then ANY local unprivileged user. No Bluetooth controller needed:
  the RFCOMM socket and its DLC pcb exist right after `socket(2)`.

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

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

## Expected
`mbufs in use` climbs by exactly 1 per successful call
(10007 -> 20007 -> 40007 across 10k+10k+20k calls on the stock netbt.ko).
Pool max is 146632 mbufs, so ~146k calls exhaust the kernel mbuf pool
permanently. On the patched module (fix.diff) the count stays flat at 7
across 60k calls and getsockopt still returns correct data (mtu=127).