DF-0589 — PoC: race sc->outq IF_DEQUEUE (ng_h4_start) vs IF_DRAIN (ng_h4_disconnect)

Privileged-capability local race. The per-node mbuf output queue sc->outq is mutated from two execution contexts (tty l_start callback vs netgraph disconnect/reset/shutdown) that hold no common cross-CPU lock: NG_H4_LOCK is just crit_enter() (per-CPU), and ng_h4_start doesn't even take that around its IF_DEQUEUE/IF_PREPEND. On SMP, concurrent dequeue and drain can both return the same mbuf → UAF / double-free.

Files

• race.c — sketch driver (flood outq via ng data socket, race disconnect against tty l_start).
• (added by per-PoC verifier) full race.c rewrite with proper ng_socket / ngctl plumbing, build.sh, run.sh, build.log, run.log, VERDICT.md, manifest.json, and — if escalation is developed — exploit.c plus the mbuf-slab grooming recipe.

Build & run

cc -O2 -lpthread -o race race.c
./race /dev/cuaU0          # user with SYSCAP_NONET_NETGRAPH capability, SMP

Expected first outcome

Kernel panic from double-free (mbuf allocator INVARIANTS, or freed-mbuf KASSERT), with backtrace pinning the fault inside m_free called from ng_h4_start (sys/netgraph7/bluetooth/drivers/h4/ng_h4.c:610):

Kernel panic: mbuf double-free / use-after-free
    m_free+0x...
    ng_h4_start+0x...
    l_start ...

Or, on a non-INVARIANTS kernel, silent corruption of the mbuf slab leading to a later panic from use-after-free in clist_btoq/m_freem.

Notes for the per-PoC verifier

• The race window is narrow: the outq is only 12 mbufs deep, and tty draining is typically bursty not continuous. Plan for many flood+disconnect iterations (thousands-to-millions) on SMP hardware. Adjust FLOOD_COUNT and the inter-disconnect pause to maximize overlap with the tty l_start callback.
• The escalation variant (mbuf-slab grooming → controlled m_ext.ext_free → ring-0 code execution) requires a sizeof(struct mbuf) and victim-object analysis; document the chosen victim in VERDICT.md. If the heap layout does not admit a stable primitive, the verdict should reflect DoS_confirmed / escalation_unverified and the finding stays at Medium.
• Verify the fix with git apply findings/poc/DF-0589/fix.diff (upgrading NG_H4_LOCK to a spinlock and wrapping IF_DEQUEUE/IF_PREPEND in ng_h4_start); after the fix the race should no longer fire.
• The same pattern exists in sys/netgraph7/tty/ng_tty.c (out of this file's scope but flagged in the finding markdown for the maintainer).

DF-0589 — VERDICT

Verdict: RACE CONFIRMED (code-level); NOT TRIGGERABLE ON THIS GUEST (sio-console-gated)

The race condition described in the finding is real at the code level — all the structural preconditions hold. However, triggering it live requires a real serial port with the sio driver (NOT a pty), and the only sio port on this guest is the kernel console (sio0), which cannot be freed for BTUARTDISC. The race is also gated behind SYSCAP_NONET_NETGRAPH (not a default unprivileged capability) and requires the netgraph7 module stack to be loaded by root (netgraph7 is compiled OUT of the default X86_64_GENERIC kernel).

What was confirmed

1. NG_H4_LOCK is per-CPU only (the root cause)

sys/netgraph7/bluetooth/drivers/h4/ng_h4_var.h:88-89:

#define NG_H4_LOCK(sc)    crit_enter();
#define NG_H4_UNLOCK(sc)  crit_exit();

DragonFly crit_enter(9) blocks preemption and defers IPIs on the current CPU only — it provides zero cross-CPU exclusion. Two CPUs can both be inside NG_H4_LOCK simultaneously.

2. ng_h4_start does IF_DEQUEUE without NG_H4_LOCK

sys/netgraph7/bluetooth/drivers/h4/ng_h4.c:572-648: - Line 579: lwkt_gettoken(&tp->t_token); — acquires the tty token only. - Line 592: IF_DEQUEUE(&sc->outq, m); — no NG_H4_LOCK held. - Line 615: IF_PREPEND(&sc->outq, m); — no NG_H4_LOCK held. - Lines 601/620/638: NG_H4_LOCK is acquired only briefly for stat counter updates.

3. ng_h4_disconnect / rcvmsg / shutdown do IF_DRAIN with crit_enter only

• ng_h4_disconnect (line 729-743): NG_H4_LOCK (crit_enter) → IF_DRAIN (line 735) → unlock. Does NOT acquire tp->t_token.
• ng_h4_rcvmsg NGM_H4_NODE_RESET (line 886): IF_DRAIN inside NG_H4_LOCK.
• ng_h4_shutdown (line 773): IF_DRAIN without even NG_H4_LOCK.

4. The ONLY concurrent execution path: sio siopoll → l_start

The finding claims ng_h4_start runs from the tty l_start line-discipline callback concurrently with netgraph methods. This is correct — but with a critical DragonFly-specific nuance:

Exhaustive search of the entire sys/ tree reveals that linesw[].l_start is called from exactly one place in the kernel:

sys/dev/serial/sio/sio.c:2241    (*linesw[tp->t_line].l_start)(tp);

This is inside siopoll() (line 2176), which is registered as a Software Interrupt (SWI) handler:

sys/dev/serial/sio/sio.c:1209    register_swi_mp(SWI_TTY, siopoll, ...);

The general tty layer's ttstart() (sys/kern/tty.c:1549) does NOT call l_start — it only calls tp->t_oproc. On DragonFly, pty-based triggering does not work because l_start is never invoked for pty devices.

So the race fires ONLY on systems with a real sio serial port where: 1. siopoll (SWI context, CPU A) calls l_start → ng_h4_start → IF_DEQUEUE 2. The netgraph writer thread (CPU B) processes ng_h4_disconnect/RESET → IF_DRAIN 3. Both operate on sc->outq with no common cross-CPU lock → double-free / UAF

5. FORCE_WRITER serializes netgraph-internal calls

NG_NODE_FORCE_WRITER(sc->node) at line 215 ensures all netgraph methods (rcvdata, rcvmsg, disconnect, shutdown) are serialized. The callout path (ng_h4_process_timeout → ng_h4_start) also goes through ng_callout which sets NGQF_WRITER (sys/netgraph7/netgraph/ng_base.c:~3260), so it is also serialized. Only the sio siopoll → l_start path bypasses FORCE_WRITER.

Why it was NOT triggered live on this guest

1. pty doesn't call l_start: The DragonFly tty layer's ttstart() calls tp->t_oproc, not linesw[].l_start. A pty-based PoC cannot exercise the race. (Confirmed: 80 seconds × 4M RESET + 4M data packets on pty → no panic.)

2. sio0 is the console: The guest has one sio port (sio0 at 0x3f8, IRQ4) which is the kernel console. Opening it for BTUARTDISC returns EBUSY because the console subsystem holds it. Getty was killed but the kernel console driver retains the reference.

3. Netgraph7 compiled out of GENERIC: NNETGRAPH7_BLUETOOTH_H4 = 0 in the default kernel config. Requires root kldload of netgraph7 core + ng_socket + ng_h4 modules.

4. Capability gate: ng_h4_open (line 157) requires SYSCAP_NONET_NETGRAPH — not a default unprivileged capability. Verified: maxx (uid 1001) gets EPERM on TIOCSETD BTUARTDISC.

Impact assessment

Exploit chain (Phase 6 assessment)

This is a memory-corruption class (potential mbuf double-free / UAF), so Phase 6 escalation assessment is required. However:

Valid hard blocker — root-only reachability: The bug's write primitive (IF_DEQUEUE / IF_DRAIN on a shared mbuf queue) is reachable ONLY when: 1. An admin has loaded the netgraph7 module stack (root kldload) 2. The user holds SYSCAP_NONET_NETGRAPH (delegated capability) 3. A real sio serial port is available and not the console

On the default GENERIC kernel, netgraph7 is not compiled in and the code path is dead. There is no unprivileged path to the write without root module loading. This meets the Phase 6 valid hard blocker criterion: "The write is reachable only from an already-root context (kldload / wheel-only ioctl)".

Even with root-loaded modules + delegated capability, the race is narrow (2-3 instruction window in IF_DEQUEUE vs IF_DRAIN) and the realistic outcome is a DoS panic (INVARIANTS mbuf double-free detection), not reliable code execution. The speculative m_ext.ext_free hijack chain described in the finding is unverified.

No uid0 escalation was attempted because the bug is not reachable from an unprivileged user on the default kernel. Documented as a root→kernel hardening gap with DoS impact.

PoC changes

Rewrote race.c from the non-compiling sketch into a working harness that: - Constructs netgraph7-format ng_mesg manually (NG_VERSION=8, 32-bit arglen) since the system's libnetgraph/ngctl use the incompatible old-netgraph ABI - Creates pty + BTUARTDISC + ng socket node + hook connection correctly - Races data flooding + NGM_H4_NODE_RESET (IF_DRAIN) for 60-80 seconds - Also created race_sio.c variant targeting real sio ports (not usable on this guest due to console conflict, but correct for systems with a free serial port)

The pty-based PoC confirmed 4M+ RESET + 4M+ data iterations with no panic, which is expected — the pty path doesn't exercise l_start. The PoC is kept as a functional harness; on a system with a free sio port and the right capabilities, it would exercise the actual race via race_sio.

Recommended fix

Upgrade NG_H4_LOCK from crit_enter/crit_exit to a real spinlock, and wrap the IF_DEQUEUE/IF_PREPEND in ng_h4_start with it. This matches the finding's recommendation. See fix.diff.

The same pattern (crit_enter as the only outq lock, unprotected IF_DEQUEUE in the l_start method) also exists in sys/netgraph7/tty/ng_tty.c and should be fixed there as well (flagged for the maintainer, out of scope for this finding).

Fix validation

The fix (fix.diff) was applied to the in-guest source and the ng_h4.ko module was rebuilt successfully. All three netgraph7 modules (netgraph core, ng_socket, ng_h4) loaded correctly. The PoC ran for 30 seconds (1.37M data packets + 1.36M RESET messages) on the fixed module with no panic and the guest stayed up.

Note: Since the pty-based PoC cannot exercise the actual race path (l_start is only called by siopoll for real serial ports), this validates that the fix compiles, loads, and does not introduce regressions — but cannot directly demonstrate the fix preventing the race (which requires a free sio serial port).

fix_status: not_testable — the race cannot be triggered on this guest (no free sio port, pty doesn't call l_start), so the fix's effectiveness against the specific race cannot be verified live. The fix is compile-validated, load-validated, and correct by code inspection.

Unrelated panic observed

During heavy PoC operations (1M+ ng_socket control messages), an unrelated panic occurred in the socket receive path (NOT in ng_h4):

panic: memory chunk 0xfffff8004f0a407f is already allocated!
chunk_mark_allocated → _kmalloc → dup_sockaddr → soreceive → kern_recvmsg

This is a separate issue (likely a double-allocation or UAF in the ng_socket/ netgraph7 message handling under heavy load), not the DF-0589 outq race. Documented in panic.txt for reference.