{
  "finding_id": "DF-5762",
  "status": "reproduced",
  "reproduced": true,
  "impact": "dos",
  "confidence": "certain",
  "verdict": "Reproduced with the DF-5760 rig (verbatim production RFCOMM sources): RFCOMM_CHANNEL()s 0x2f mask lacks bit 4, so inbound DLCIs for server channels 16..30 are remapped (16->0, 17->1 ... 30->14). An incoming PN/SABM for channel 17 (DLCI 34/35) matches and is served by the CHANNEL-1 listener and the accepted DLC is stamped rd_laddr.bt_channel = 1 (MASK-CHECK: DLCI 34 (channel 17) planted, rd_laddr.bt_channel = 1 in run.log) - in production this mis-delivers one local services connections/data to another services socket on the same multiplexer; channel 16 (DLCI 32/33 -> chan 0) can never match a listener and is permanently unreachable (DM). Local listeners/connections use the correct MKDLCI (0x1f) - only the inbound extraction is broken. RFCOMM_CHANNEL_MAX is 30, so channels 16..30 are fully legal configurations.",
  "exploit_chain": "Remote peer of an established RFCOMM session connects to server channel N in 17..30 -> rfcomm_dlc_newconn matches the listener on channel (N & 0x2f) -> the wrong server socket accepts the connection and receives the data (cross-service trust-boundary crossing on one multiplexer). Channel 16 services are unreachable. No memory corruption.",
  "evidence": "run.log: MASK-CHECK: DLCI 34 (channel 17) planted, rd_laddr.bt_channel = 1 + the matching newconn #N (listener upper 0x1) tag; channel 16 NOT planted (DM, chan 0); MASK-BUG: RFCOMM_CHANNEL(33)=0 (16 & 0x2f), RFCOMM_CHANNEL(35)=1 (17 & 0x2f), RFCOMM_CHANNEL(61)=14 (30 & 0x2f). run.fix.log: MASK-BUG: RFCOMM_CHANNEL(33)=16 ... (35)=17 ... (61)=30, newconn #2 (listener upper 0x11) (the correct channel-17 listener), MASK-CHECK: ... rd_laddr.bt_channel = 17.",
  "kernel_refs": [
    "sys/netbt/rfcomm.h:217",
    "sys/netbt/rfcomm.h:224",
    "sys/netbt/rfcomm_dlc.c:88",
    "sys/netbt/rfcomm_dlc.c:100",
    "sys/netbt/rfcomm_dlc.c:107",
    "sys/netbt/rfcomm_dlc.c:133"
  ],
  "poc_changes": "Found BY the DF-5760 rig: the channel sweep planted ch17..30 against shifted listeners (dlci 0x23/ch17 -> listener upper 0x1, ..., dlci 0x3d/ch30 -> listener upper 0xe) and ch16 drew a DM; a dedicated MASK-CHECK PN (correct-direction DLCI 34) was added to make the mis-attribution explicit. Shares the DF-5760 rig files verbatim (see DF-5760/ for harness.c and stubs).",
  "attempts": 1,
  "guest_uname": "DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64",
  "runtime_sec": 600,
  "guest_dirty": 0,
  "build_cmd": "cd /root/df5760 && sh build.sh   (same rig as DF-5760)",
  "run_cmd": "kldload /root/df5760/rfcomm_pn_harness.ko && sysctl hw.rfcomm_pn_fire=1   (markers: MASK-CHECK / MASK-BUG / listener-upper tags)",
  "code_hash": "137c459cd205977dfe37c2d74b48fe42bfc8a242f0989ef27c9ae28946626894",
  "notes": "The macro is identical in the 2007 NetBSD import lineage; MKDLCI uses 0x1f, RFCOMM_CHANNEL uses 0x2f - a one-character defect. Because channels >= 16 are rarely deployed (most services sit on 1..10), this survived 19 years. Filed Low: remote-triggerable wrong-service connection routing + channel-16 unreachability, no memory unsafety.",
  "recommended_fix": "Change the RFCOMM_CHANNEL mask from 0x2f to 0x1f (one line, see fix.diff).",
  "fix_status": "fixed",
  "fix_baseline_reproduced": true,
  "fix_patched_reproduced": false,
  "fix_verdict": "One-line mask fix (0x2f -> 0x1f in sys/netbt/rfcomm.h) applied to the guests /usr/src copy, rig rebuilt from the patched verbatim sources: RFCOMM_CHANNEL(33)=16 / (35)=17 / (61)=30 (printed), the channel-17 PN now matches the channel-17 listener (newconn #2 (listener upper 0x11)) and the DLC is stamped rd_laddr.bt_channel = 17. Guest alive.",
  "fix_evidence": "run.fix.log: MASK-BUG: RFCOMM_CHANNEL(33)=16 (16 & 0x2f), RFCOMM_CHANNEL(35)=17 ... (post-fix values), [upper] newconn #2 (listener upper 0x11), MASK-CHECK: DLCI 34 (channel 17) planted, rd_laddr.bt_channel = 17 (17 == correct match)."
}