DF-0281 — PoC evidence pack

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

Verdict: REPRODUCED (code/object-code level, certain)

The bug is confirmed three independent ways:

1. Static line-by-line trace — every hop from peer PN frame to the unguarded divisor is cited path:line in VERDICT.md.
2. Actual kernel module build + objdump — ng_btsocket.ko builds cleanly from /usr/src/sys/netgraph7/bluetooth/socket/ against the audit kernel; objdump confirms the unguarded idiv %r8 (divisor = pcb->mtu) at module offset 0xb418 with no preceding zero-check. (objdump_unpatched.dis, idiv_comparison.txt)
3. Userspace arithmetic replication — divzero_proof.c reproduces the exact kernel integer arithmetic; with pcb->mtu = 0 it raises SIGFPE 3/3 runs.

No runtime trigger on this KVM guest: ng_btsocket is not in X86_64_GENERIC, the freshly-built .ko won't kldload (netgraph ABI mismatch), and reaching the live path needs real bluetooth HW anyway. The object-code-level proof is the accepted reproduction (precedent: DF-0594 / DF-0616).

What this pack contains

• divzero_proof.c — userspace replication of the exact kernel arithmetic (every step annotated with its kernel source line).
• build.sh / run.sh — build & run the harness.
• build.log / run.log / run.fixed.log / run.stress.log — full output.
• module_build.log — building the actual ng_btsocket.ko from source (unpatched baseline).
• fix_build.log — rebuilding ng_btsocket.ko with fix.diff applied.
• objdump_unpatched.dis / objdump_patched.dis — full disassemblies.
• idiv_comparison.txt — focused before/after object-code comparison.
• fix.diff — git apply-able fix (validated both directions).
• env.txt — guest environment + reachability evidence.
• VERDICT.md — full narrative.
• manifest.json — machine-readable catalog.

Build (userspace harness)

./build.sh

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

Run

./run.sh

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

Object-code proof (the strong evidence)

Build the actual vulnerable module and disassemble:

ssh dfbsd 'cd /usr/src/sys/netgraph7/bluetooth/socket && make &&
           objdump -d ng_btsocket.ko | grep idiv'
# -> exactly one "idiv %r8" at offset 0xb418, divisor = pcb->mtu, NO guard

Apply the fix and rebuild:

ssh dfbsd 'cd /usr/src && patch -p1 < /root/fix.diff &&
           cd sys/netgraph7/bluetooth/socket && make &&
           objdump -d ng_btsocket.ko | grep -B3 idiv'
# -> "idiv %rdi" at 0xb4b2, preceded by "test %cx,%cx; je <return>" at 0xb470

See idiv_comparison.txt for the annotated before/after.

Reproducing the kernel panic

Cannot be done on this master DEV guest (no bluetooth HW, module won't load). 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

REPRODUCED at code/object-code level (certain). The divide-by-zero is real, deterministic, and unambiguous — confirmed three independent ways:

1. Static line-by-line trace of the cited path in the audited master DEV source (every hop cited path:line below).
2. Actual kernel module build: ng_btsocket.ko compiles cleanly from /usr/src/sys/netgraph7/bluetooth/socket/ against the audit-source kernel (DragonFly 6.5-DEVELOPMENT #0, Thu Jul 2 06:02:54 UTC 2026). The vulnerable function ng_btsocket_rfcomm_send_credits is inlined into ng_btsocket_rfcomm_sessions_task and objdump confirms the unguarded idiv %r8 instruction (divisor = pcb->mtu, offset 0x24 of the PCB) at module offset 0xb418. There is no zero-check between loading the divisor and the idiv. (Full disassembly: objdump_unpatched.dis; focused comparison: idiv_comparison.txt.)
3. Userspace arithmetic replication (divzero_proof.c) reproduces the exact kernel integer arithmetic on the confirmed path; with pcb->mtu = 0 it raises SIGFPE (the userspace analogue of in-kernel #DE) 3/3 runs — deterministic, as expected for a zero-divisor integer divide.

It is NOT runtime-triggerable on this KVM guest because (a) the ng_btsocket module is neither compiled into X86_64_GENERIC nor shipped as a .ko, and (b) kldload of the freshly-built module fails with a netgraph ABI version mismatch (KLD ng_btsocket.ko: depends on netgraph - not available or version mismatch) — and even with the module loaded, reaching the live path requires a real RFCOMM session over L2CAP/HCI, i.e. real bluetooth hardware, which the QEMU guest lacks and DragonFlyBSD provides no virtual/software HCI device for. The object-code-level proof is the accepted reproduction (precedent: DF-0594 TKIP / DF-0616 netmap code-level harnesses; here it is stronger — the actual vulnerable .ko is built and disassembled, not just a userspace reimplementation).

This supersedes the prior inconclusive run (id 23): that run had only the userspace arithmetic replication; this run adds the real-module build + objdump proof + object-code-level fix validation.

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 (commit 6cc80ee9).

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. (Confirmed by reading the source and by the objdump: set_pn is inlined and the le16toh(mtu) store reaches the same 0x24(%r13) slot that the idiv later reads.)

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), from ng_btsocket_rfcomm_receive_frame (:2022), from ng_btsocket_rfcomm_session_receive (:1679). The 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 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 (0x0003) 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.

Object-code-level proof (the new evidence)

The vulnerable .ko was built from /usr/src (same audit commit) and disassembled. The inlined send_credits lives inside ng_btsocket_rfcomm_sessions_task. objdump shows exactly one idiv in the entire module, and it is the unguarded divide by pcb->mtu:

UNPATCHED ng_btsocket.ko — idiv at offset 0xb418 (NO guard before it):
    b3df:  movzwl 0x24(%r13),%edi      ; edi  = pcb->mtu (the divisor)
    ...
    b3fa:  movzwl %di,%r8d              ; r8   = pcb->mtu (divisor, zero-extended)
    ...
    b413:  mov    %rsi,%rax             ; rax  = ssb_space(...) (dividend)
    b416:  cqto                          ; sign-extend
    b418:  idiv   %r8                   ; *** DIVIDE BY pcb->mtu — NO GUARD ***
                                        ; *** if r8==0 (peer PN mtu=0) -> #DE -> panic ***

There is no test/je/jne on r8/edi between loading pcb->mtu (b3df/b3fa) and the idiv (b418). The divide is unconditional. This is the compiled form of the unguarded line :3283. (Full module disassembly in objdump_unpatched.dis.)

Why it does NOT reproduce at runtime on this guest

So the vulnerable code is dead on the running kernel image (the module is not loaded), and even rebuilding+loading 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 object-code-level proof (module build + objdump + userspace arithmetic replication) is the accepted reproduction.

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 & validation

fix.diff (validated: applies cleanly with patch -p1 both directions) adds 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 any pre-verification proposal (no finding markdown exists for DF-0281; this is the authoritative verified fix).

Object-code-level fix validation (Phase 8)

The fix was validated at the .ko object-code level (a full kernel rebuild + runtime trigger is impossible: no bluetooth HW + module won't load). The patched module was rebuilt from the same source with fix.diff applied, and objdump confirms the compiler now emits a guard immediately before the idiv:

PATCHED ng_btsocket.ko — idiv at offset 0xb4b2, GUARDED by test/je:
    b46b:  movzwl 0x24(%r13),%ecx       ; ecx = pcb->mtu (the divisor)
    b470:  test   %cx,%cx                ; *** THE GUARD: is pcb->mtu == 0? ***
    b473:  je     b7d3                   ; *** YES -> jump to clean return (b7d3),
                                        ;     SKIPPING the divide entirely ***
    ...
    b498:  movzwl %cx,%edi               ; edi = pcb->mtu (KNOWN NON-ZERO here)
    ...
    b4b0:  cqto
    b4b2:  idiv   %rdi                   ; *** DIVIDE — only reached if pcb->mtu != 0 ***

    b7d3:  mov    0xb8(%rbx),%eax       ; <-- je target: clean return path
    b7d9:  jmpq   ab8f                   ;     (function epilogue)

The test %cx,%cx; je b7d3 at b470/b473 is exactly the compiler's emission of if (pcb->mtu == 0) return (EINVAL);. When pcb->mtu == 0, execution jumps past the idiv to b7d3 (clean return). The divide-by-zero is now impossible. (Full module disassembly in objdump_patched.dis.)

The userspace arithmetic replication (divzero_proof_fixed, compiled with -DFIX_MTU) also completes with NO FAULT when pcb->mtu is clamped to RFCOMM_DEFAULT_MTU, confirming the arithmetic path is closed.

Before/after contrast: - Unpatched .ko: one idiv %r8, no preceding zero-check on the divisor → #DE when pcb->mtu == 0 → kernel panic. - Patched .ko: idiv %rdi preceded by test %cx,%cx; je <return> → divide skipped when pcb->mtu == 0 → no fault.

PoC changes (this run vs prior inconclusive run)

The PoC sources (divzero_proof.c, build.sh, run.sh, fix.diff) are unchanged — the prior run's harness and fix were already correct. What changed is the evidence: this run adds (a) the actual ng_btsocket.ko module build log proving the vulnerable code links cleanly against the audit kernel, (b) objdump_unpatched.dis / objdump_patched.dis proving the unguarded idiv exists in the compiled binary and is guarded after the fix, and (c) idiv_comparison.txt — the focused before/after object-code comparison. This elevates the verdict from inconclusive (userspace arithmetic only) to reproduced (object-code-level proof on the real built module).