# DF-5760 VERDICT

**Status: reproduced** (rig, production code verbatim; deterministic; guest up)
**Impact: dos** — remote-peer-triggered permanent lockout of local RFCOMM
outbound connections + rogue DLC/socket allocation in the wrong DLCI space.

## What was run

KLD rig `rfcomm_pn_harness` (see README): production `rfcomm_session.c`,
`rfcomm_dlc.c`, `rfcomm_upper.c` copied byte-identical from
`/usr/src/sys/netbt` (md5s in setup.log), compiled against a stub L2CAP
layer.  Frames from the "remote peer" are injected through the production
entry point `rfcomm_session_input()` — the same callback the real L2CAP
layer invokes.  Upper-layer callbacks stand in for the socket layer
(`rfcomm_sock_newconn()` = sonewconn + return so->so_pcb).

## Root cause (path:line)

* `sys/netbt/rfcomm_session.c:1322-1331` — `rfcomm_session_recv_mcc_pn()`
  PN-command path calls `rfcomm_dlc_newconn(rs, pn.dlci)` with no
  direction validation (contrast `rfcomm_session_recv_sabm()`
  at rfcomm_session.c:738-742, which *does* check).
* `sys/netbt/rfcomm_dlc.c:88` — `chan = RFCOMM_CHANNEL(dlci)` and the
  listener matching at rfcomm_dlc.c:92-111 consider only the channel,
  never the direction bit.
* `sys/netbt/rfcomm_dlc.c:128-140` — the fabricated DLC is stamped with
  the peer-chosen (wrong-direction) `rd_dlci` and inserted on the session.

## Reproduced behaviour (run.log, deterministic, first shot)

1. Local service listening on channels 1..30; responder session opened
   by the peer (SABM(0)); baseline local `rfcomm_connect(ch 4)` accepted
   (DLCI 9 — confirming local DLCIs are the odd/responder direction).
2. One PN command with DLCI 7 (channel 3, responder direction = OUR
   direction) → production `rfcomm_dlc_newconn()` matched the channel-3
   listener, called its newconn (socket child created in production),
   stamped `rd_dlci = 7`, inserted it: `POISON-CONFIRMED`.
3. Legit SABM(6) still opens DLCI 6 → the same channel 3 now hosts TWO
   DLCs, one of them bogus (`DUP-CHANNEL`).
4. Every subsequent local `rfcomm_connect(ch 3)` hits
   `rfcomm_upper.c:181-182` (`rfcomm_dlc_lookup(rs, 7) != NULL`) →
   **EBUSY forever** (`LOCAL-CONNECT ... -> 16`).
5. Sweeping the poison over all 30 channels: 28/29 channels refuse local
   connect with EBUSY (`POISON-SWEEP`) — the peer can lock the local
   RFCOMM client out of every server channel.  (The 29th, ch16, is
   blocked by the *separate* channel-mask bug DF-5762: `16 & 0x2f = 0`
   matches no listener.  Every other channel ≥ 17 was still poisoned —
   via the wrong listener, see DF-5762.)

Each planted DLC allocates a socket (sonewconn) + DLC in production;
they linger in `RFCOMM_DLC_WAIT_CONNECT` until the session dies
(`recv_sabm` rejects the wrong-direction SABM that would complete them).

## Threat

The remote peer of any established RFCOMM session (Bluetooth adjacency,
L2CAP PSM 3): permanent DoS of *local outbound* RFCOMM connections to
that peer, plus unkillable rogue half-open DLC/socket pairs.  No memory
corruption (the planted DLCs are correctly refcounted by the socket
layer); severity Low/Medium boundary — filed Low→Medium given the
whole-channel lockout.  Precondition: netbt loaded + RFCOMM session
between attacker and victim service.

## Fix validation

`fix.diff` adds the missing direction check to `recv_mcc_pn` (identical
in form to `recv_sabm`'s).  Applied inside the guest's `/usr/src`
copy; rig rebuilt from the patched verbatim sources; same harness run:

* PN(DLCI 7) now answered with DM, no DLC created
  (`DUP-CHANNEL ... planted DLCI 7 (state -1)`, `newconn calls: 2`).
* `LOCAL-CONNECT: rfcomm_connect(ch 3) -> 0` — **accepted**.
* `POISON-SWEEP: 1/29` (the single EBUSY is ch4's own legitimate
  baseline DLC from step 1).
* Guest alive (`uptime` in transcript).

## Rig notes / deviations

* The first rig iteration panicked in harness code: the DF-5733 stub's
  `l2cap_sockaddr()` returned a fixed bdaddr so each of the 30 listeners
  created its own listening session and exhausted the stub's channel
  table (`rfcomm_session_alloc()` → NULL, compiler-hoisted
  `rs->rs_l2cap` load faulted).  Fixed by making the stub report
  BDADDR_ANY (the natural "bind any" setup) so listeners share one
  session, exactly as production does when binding ANY.
* Two rig runs were lost to a stale module load (KLD unload is EBUSY);
  reboot between runs is required — noted in run.sh.

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