DF-0281 — PoC evidence pack

Finding: ng_btsocket_rfcomm_set_pn copies a peer-supplied PN mtu into pcb->mtu with no validation; ng_btsocket_rfcomm_send_credits later divides ssb_space / pcb->mtu unconditionally. A peer PN with mtu=0 plus one UIH data frame → divide-by-zero #DE → kernel panic. CWE-369 (divide-by-zero), severity High.

What this pack contains

• divzero_proof.c — code-level proof (userspace). Replicates the exact kernel integer arithmetic + control flow on the confirmed vulnerable path (every step annotated with its kernel source line). It is NOT a kernel trigger: the bluetooth RFCOMM module is not present on the audited guest (see env.txt and VERDICT.md for the full reachability analysis).
• build.sh / run.sh — exact, self-contained build & run commands.
• build.log / run.log / run.stress.log — full untrimmed output.
• env.txt — guest environment + reachability evidence (kldstat, kldload, module search, kernel-symbol count, AF_BLUETOOTH socket test, src presence).
• fix.diff — standalone git apply-able unified diff fixing the bug (validated with git apply --check and patch --dry-run, both rc=0).
• VERDICT.md — full narrative, line-by-line static trace, reachability caveat.
• manifest.json — machine-readable catalog.

Build

./build.sh

Produces divzero_proof (vulnerable arithmetic) and divzero_proof_fixed (same code compiled with -DFIX_MTU, which clamps pcb->mtu).

Run

./run.sh

Runs the vulnerable path (expects the divide-by-zero, surfaced as SIGFPE), then the guarded path (expects clean completion).

Expected output

Vulnerable path (bug present — the kernel arithmetic reaches the zero divisor):

STEP 1: peer PN with mtu=0 processed by set_pn (line 3019); now pcb->mtu = 0  <-- NO validation was applied
STEP 2: ... --rx_cred=20 <= MAX_CREDITS/2 -> send_credits() called (line 2429)
STEP 3: send_credits line 3283: credits = ssb_space / pcb->mtu ...
### SIGFPE: divide by zero at step 3 (send_credits, line 3283) ###
PROOF: pcb->mtu==0 reached the unguarded divisor -> kernel would #DE/panic

Guarded path (fix active): prints NO FAULT: pcb->mtu was guarded before the divisor (fix active); credits path completed. and exits 0.

Reproducing the kernel panic

Cannot be done on this master DEV guest: the ng_btsocket module is not built into X86_64_GENERIC, is not present as a .ko, cannot be kldload-ed, the socket domain AF_BLUETOOTH is not registered, there is no kernel source on the guest to build it, and reaching the live path additionally needs a real bluetooth adapter (or a virtual HCI device DragonFlyBSD does not provide). On a host that does have bluetooth hardware and ng_btsocket loaded, the panic is produced by a malicious peer that: 1. opens an L2CAP channel on PSM RFCOMM (0x0003) and completes the RFCOMM session handshake, 2. sends a PN MCC frame with mtu = 0 and flow_control = 0xf0 (enables CFC), 3. sends a single UIH data frame on the DLC to drive rx_cred down to RFCOMM_MAX_CREDITS/2, which calls send_credits() → #DE → panic.

See VERDICT.md for the full line-by-line trace.

DF-0281 — netgraph7 RFCOMM divide-by-zero via peer PN mtu=0

Verdict

INCONCLUSIVE at runtime / CONFIRMED at code level. The divide-by-zero is real and unambiguous in the audited master DEV source (static proof below, deterministic). It is NOT reachable on the running guest because the entire netgraph7 bluetooth stack is absent: ng_btsocket is neither compiled into X86_64_GENERIC nor present as a loadable module (kldload ng_btsocket → ENOENT, nm /boot/kernel/kernel | grep -c ng_btsocket_rfcomm → 0, socket(AF_BLUETOOTH=31,…) → -1), there is no kernel source on the guest to build it, and even if the module were loaded the vulnerable path additionally requires a live RFCOMM session over L2CAP/HCI, which needs a real bluetooth adapter (or a virtual/software HCI device that DragonFlyBSD does not ship — the only HCI transports are ng_h4/UART, ng_ubt/USB, ng_bt3c/PCMCIA, ng_ubtbcmfw/USB-firmware, all hardware-backed). The QEMU/KVM guest has no bluetooth hardware. So: code-level bug = certain; runtime trigger on this kernel = not possible → inconclusive (per the rubric: "needs specific HW / missing koption").

The bug (confirmed line-by-line)

All citations are sys/netgraph7/bluetooth/socket/ng_btsocket_rfcomm.c unless noted; line numbers are current master DEV.

1. pcb->mtu is u_int16_t (sys/netgraph7/bluetooth/include/ng_btsocket_rfcomm.h:176). Default on DLC creation is RFCOMM_DEFAULT_MTU = 667 (ng_btsocket_rfcomm.c:432). The only writer that takes a peer-controlled value is set_pn.

2. ng_btsocket_rfcomm_set_pn(pcb, cr, flow_control, credits, mtu) (:3013-3043) performs, at :3019: c pcb->mtu = le16toh(mtu); with no validation — no != 0, no range check. A PN (Parameter Negotiation) MCC frame carries a 16-bit MTU field that is fully attacker- chosen; mtu = 0 is copied verbatim.

3. PN reachability from a peer frame. ng_btsocket_rfcomm_receive_pn (:2881) only checks pn->dlci != 0 (:2899); it never inspects pn->mtu. It calls set_pn at :2913 (PN request, existing DLC), :2931 (PN response), and :2955 (incoming connection). receive_pn is called from ng_btsocket_rfcomm_receive_mcc (:2553), which is called from ng_btsocket_rfcomm_receive_frame (:2022), which is called from ng_btsocket_rfcomm_session_receive (:1679). That session-receive routine pulls frames off the L2CAP socket with soreceive(s->l2so, …) at :1665 — i.e. the data arrives from a remote RFCOMM peer over L2CAP/HCI. No local-only / software path feeds this socket.

4. The unguarded divisor. ng_btsocket_rfcomm_send_credits(pcb) (:3268-3309) computes, at :3283: c credits = ssb_space(&pcb->so->so_rcv) / pcb->mtu; ssb_space() returns long (sys/sys/socketvar.h:270-282). The expression is therefore long / u_int16_t → on x86-64 an idiv with divisor 0 when pcb->mtu == 0. A zero divisor traps as #DE (divide error) regardless of the dividend — 0/0 faults just as N/0 does. → kernel panic.

5. Trigger sequence & ordering (finding's central claim is correct). ng_btsocket_rfcomm_receive_uih (:2356), on a data-bearing UIH frame (m0->m_pkthdr.len > 0, :2424) with credit-based flow control on (:2426), decrements rx_cred (:2428) and, when it has dropped to <= RFCOMM_MAX_CREDITS/2, calls send_credits(pcb) at :2429. That call site is before the MTU-oversize check at :2438 (if (m0->m_pkthdr.len > pcb->mtu)). So the divide-by-zero at :3283 executes before any code that could indirectly notice mtu == 0. Confirmed.

Net: a remote peer that (a) establishes an L2CAP channel on PSM RFCOMM and an RFCOMM session, (b) sends a PN MCC with mtu = 0 and flow_control = 0xf0 (enabling CFC), and (c) sends one UIH data frame to drive rx_cred down to MAX_CREDITS/2, deterministically panics the kernel via #DE. No authentication is required (RFCOMM/SPP is unauthenticated by design). This matches the finding's claim exactly.

Why it does NOT reproduce at runtime on this guest

So the vulnerable code is dead on this kernel image, and even rebuilding it would not help: the only way to feed a PN frame to receive_pn is over a real RFCOMM/L2CAP/HCI session, and DragonFlyBSD has no virtual HCI device. The QEMU guest has no bluetooth adapter.

Code-level proof

divzero_proof.c is a userspace replication of the exact kernel integer arithmetic and control flow on the confirmed path — every arithmetic / control operation is annotated with its kernel source line. It is not a kernel trigger (the module is absent; it cannot be). It demonstrates:

• set_pn accepting a peer mtu = 0 with no validation (pcb->mtu becomes 0);
• the UIH-driven credit decrement reaching the send_credits call site; and
• the divisor pcb->mtu being evaluated, which on x86-64 raises the #DE trap — in the harness surfaced as SIGFPE, caught and reported.

Build & run: ./build.sh && ./run.sh. Decisive output (run.log):

STEP 1: peer PN with mtu=0 processed by set_pn (line 3019); now pcb->mtu = 0  <-- NO validation was applied
STEP 2: ... --rx_cred=20 <= MAX_CREDITS/2 -> send_credits() called (line 2429)
STEP 3: send_credits line 3283: credits = ssb_space / pcb->mtu ...
### SIGFPE: divide by zero at step 3 (send_credits, line 3283) ###
PROOF: pcb->mtu==0 reached the unguarded divisor -> kernel would #DE/panic

Re-running 3× (run.stress.log) hits SIGFPE every time — deterministic, as expected for a zero-divisor integer divide. Compiling with -DFIX_MTU (clamping pcb->mtu to RFCOMM_DEFAULT_MTU) makes the path complete with no fault, confirming the fix closes the arithmetic path.

Exploit chain

Not a memory-corruption class — it is a single-instruction DoS (divide-by-zero → #DE → panic). There is no further primitive to derive from the #DE itself: on x86 the trap is non-resumable and the kernel panics. Weaponization = remote unauthenticated kernel panic of any DragonFlyBSD host that (a) has the ng_btsocket module loaded (or bluetooth compiled in) and (b) has a bluetooth adapter up and accepting RFCOMM connections (SPP). Single malformed PN + one UIH frame; deterministic. Availability-only (C:N/I:N/A:H), matching the finding's CVSS AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — adjacency is required (bluetooth range), there is no confidentiality or integrity impact.

Recommended fix

fix.diff (validated: git apply --check and patch --dry-run both rc=0) applies two guards, both minimal:

1. Root cause — in ng_btsocket_rfcomm_set_pn (:3019), do not store a zero MTU; fall back to RFCOMM_DEFAULT_MTU: pcb->mtu = (le16toh(mtu) != 0) ? le16toh(mtu) : RFCOMM_DEFAULT_MTU;
2. Defense-in-depth at the fault site — in ng_btsocket_rfcomm_send_credits (:3283), bail out before the divisor: if (pcb->mtu == 0) return (EINVAL);

Either guard alone prevents the panic; both together close the untrusted-input path and protect the divisor regardless of how pcb->mtu could later become zero. This supersedes the finding markdown (no markdown writeup exists for DF-0281; this is the authoritative verified fix).