# DF-5762 VERDICT

**Status: reproduced** (rig, production code verbatim; deterministic)
**Impact: dos / cross-service mis-attribution** — inbound RFCOMM
connections for server channels 17..30 are matched to the WRONG
listening socket (channel N&0x2f) and channel 16 is permanently
unreachable.

## Root cause

`sys/netbt/rfcomm.h:217`:
`#define RFCOMM_CHANNEL(dlci) (((dlci) >> 1) & 0x2f)` — 0x2f (0b101111)
lacks bit 4, so 5-bit channel values ≥ 16 wrap: 16&0x2f=0,
17&0x2f=1 … 30&0x2f=14.  The inverse macro `RFCOMM_MKDLCI`
(rfcomm.h:224) correctly uses `& 0x1f`, so only inbound extraction is
broken.  `RFCOMM_CHANNEL_MAX` is 30 (rfcomm.h:84), i.e. channels 16..30
are fully legal — `rfcomm_listen()` accepts them (rfcomm_upper.c:320-323)
and local `rfcomm_connect()` builds correct DLCIs for them; only the
**incoming** path is broken.

Sinks: `rfcomm_dlc_newconn()` (sys/netbt/rfcomm_dlc.c:88
`chan = RFCOMM_CHANNEL(dlci)`, matching at :100/:107, stamping at
:133 `new->rd_laddr.bt_channel = chan`).

## Reproduced behaviour (run.log)

Same rig as DF-5760 (verbatim production RFCOMM sources + stub L2CAP):

* PN command, DLCI 34 (channel 17, correct initiator direction):
  `MASK-CHECK: DLCI 34 (channel 17) planted, rd_laddr.bt_channel = 1`
  and the newconn callback tag shows the **channel-1** listener matched
  ("listener upper 0x1").  In production the channel-17 client would be
  connected to the channel-1 server socket, with data flowing to the
  wrong service.
* PN command, DLCI 33 (channel 16): DM — `16 & 0x2f = 0` matches no
  listener ("channel 16 NOT planted"), channel 16 is unreachable.
* The DF-5760 sweep lines show every channel ≥ 17 matching a
  shifted-down listener (dlci 0x3d = ch30 → "listener upper 0xe").

## Fix validation (run.fix.log)

`fix.diff`: `0x2f` → `0x1f` in rfcomm.h, applied in the guest /usr/src,
rig rebuilt from the patched verbatim sources:

* `MASK-BUG: RFCOMM_CHANNEL(33)=16 ... (35)=17 ... (61)=30` (correct
  extraction).
* `newconn #2 (listener upper 0x11)` — the channel-**17** listener now
  matches; `MASK-CHECK: ... rd_laddr.bt_channel = 17`.
* Channel-16 DM gone (not re-tested standalone — channel 16 poison is
  direction-rejected by the DF-5760 fix in the same patched build; the
  mask arithmetic itself is printed and correct).

## Threat

Remote peer of an established RFCOMM session connecting to services
listening on channels 16..30: data mis-delivery between unrelated local
services (e.g. audio service socket receiving the serial-port service's
connection — a trust-boundary crossing on one multiplexer) and total
unreachability of channel 16.  No memory corruption.  Severity Low.

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