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.