DF-0586 — PoC: lockless hci_pcb list UAF race

Two-thread race to exercise the hci_mtap LIST_FOREACH traversal against a concurrent hci_sdetach → kfree(pcb).

Files

• poc_race.c — minimal reproducer (driver thread + closer thread).
• (added by per-PoC verifier) build.sh, run.sh, build.log, run.log, VERDICT.md, manifest.json, and — if escalation is developed — exploit.c plus slab-grooming recipe.

Build & run (DragonFlyBSD guest)

cc -o poc_race poc_race.c -lpthread
./poc_race

Expected first outcome

Kernel panic (Fatal trap 12: page fault while in kernel mode) with a backtrace pinning the fault inside hci_mtap (sys/netbt/hci_socket.c:~935-1011) or sbappendaddr, confirming the race.

Notes for the per-PoC verifier

• Requires an SMP DragonFly guest with a Bluetooth controller present (or a loaded ubt(4) / ng_ubt module so the unit list is non-empty and hci_mtap actually taps). Verify with dmesg | grep -i bt and kldstat | grep ubt.
• The driver thread should sendto() an opcode allowed by hci_security_check_opcode for unprivileged sockets, otherwise hci_output_cmd will reject the frame before reaching hci_mtap.
• A reproduced panic is the minimum success criterion. The escalation variant requires a sizeof(struct hci_pcb) slab analysis and a grooming spray — document the chosen victim object in VERDICT.md.
• If pru_send and pru_detach for distinct HCI sockets happen to be serialized onto the same CPU message port, the race window collapses; in that case the verdict should reflect cannot_reproduce_under_cpu_affinity with the kernel-source trace to back it up, and the finding stays as a defence-in-depth concern.

DF-0586 — Lockless global hci_pcb list UAF race

Verdict

LATENT BUG, CODE-CONFIRMED — race path unreachable from an unprivileged user on this guest (no Bluetooth controller); not runtime-demonstrable here; fix.diff source-validated (applies, compiles, links, boots, adds the missing lock symbol).

The lockless-walk-vs-free pattern the finding describes is real and is exactly where the finding says it is (sys/netbt/hci_socket.c:87, 576-577, 655-657, 935-1011). But the only walker of hci_pcb is hci_mtap, which is reachable solely from the BT-radio input path (sys/netbt/hci_unit.c:348,364,381,494,515,528) and from the hci_send→hci_output_cmd path (sys/netbt/hci_socket.c:533). Both require a populated hci_unit_list, which is only populated by hci_attach (sys/netbt/hci_unit.c:83-118) when a real Bluetooth device driver probes a controller. The audit guest has no BT controller and no loadable BT driver module, so the unit list stays empty, hci_send returns ENETDOWN at sys/netbt/hci_socket.c:505 before ever reaching hci_output_cmd, and hci_mtap is never invoked.

PF_BLUETOOTH/BTPROTO_HCI sockets themselves ARE reachable from the unprivileged maxx user once an admin kldloads netbt.ko (verified: socket(33, SOCK_RAW=3, BTPROTO_HCI=1) succeeds for maxx and calls hci_sattach/hci_sdetach for socket()/close() — but those just insert/remove a pcb into the never-walked list, so no race fires).

A kernel-module harness (df0586_harness.c) was written to call hci_mtap() directly from a kernel thread, simulating the missing BT-radio input path. With a userspace driver (poc_race.c) hammering socket(PF_BLUETOOTH,SOCK_RAW,BTPROTO_HCI)/close() to drive the real hci_sattach/hci_sdetach, the walker performed >3.3 billion hci_mtap() calls concurrently with >4 million socket open/close cycles — and the race did not fire. The reason is structural, not statistical: the INVARIANTS-ON default GENERIC slab allocator (sys/kern/kern_slaballoc.c:1559-1571) only poisons the first sizeof(weirdary) = 64 bytes of a freed chunk with WEIRD_ADDR (0xdeadc0de), but struct hci_pcb's LIST_NEXT linkage (hp_next.le_next) lives at offset 88 — outside the poison zone. So a walker reading pcb->hp_next.le_next from a concurrently-freed chunk still sees the pre-free linkage value (a valid pointer or NULL), and silently walks past it. The race's read of the freed pcb is real (it is a UAF read on hp_flags, hp_laddr, hp_pfilter, hp_efilter, which ARE in the first 64 bytes), but it doesn't fault because those reads observe either the pre-free data, the transient 0xdeadc0de poison (which the filter logic happens to treat as "skip this pcb"), or the post-realloc zeroes — none of which cause a fault. For the walker to fault, the freed chunk's hp_next would need to be overwritten with garbage, which requires cross-object slab reuse (attacker-controlled content) — the heap-grooming escalation variant the finding itself flags as the worst-case path but which is out of reach of a pure stress reproducer on this guest.

Mechanism (the bug is real)

1. The list head is a bare LIST_HEAD with no lock initializer — sys/netbt/hci_socket.c:87.
2. hci_sattach (insert path) guards LIST_INSERT_HEAD only with crit_enter()/crit_exit() at sys/netbt/hci_socket.c:655-657. On DragonFly crit_enter() blocks local-CPU preemption only — it provides NO cross-CPU exclusion.
3. hci_sdetach (remove path) has NO protection at all — bare LIST_REMOVE(pcb, hp_next); kfree(pcb, M_PCB); at sys/netbt/hci_socket.c:576-577.
4. hci_mtap (the only walker) uses bare LIST_FOREACH(pcb, &hci_pcb, hp_next) at sys/netbt/hci_socket.c:935 and dereferences pcb->hp_flags, pcb->hp_laddr, pcb->hp_efilter, pcb->hp_pfilter, &pcb->hp_socket->so_rcv.sb, then calls sbappendaddr/sorwakeup on the freed/reused hp_socket at sys/netbt/hci_socket.c:1004-1006.
5. The only lock in the entire sys/netbt/ tree is unit->hci_devlock (sys/netbt/hci_unit.c:102), a per-unit device-queue lock. There is no pcb-list lock. (grep -rn 'lockmgr.*hci_pcb\|hci_pcb_lock' sys/netbt returns zero hits pre-fix.)

So on a host that DOES have a Bluetooth controller (or an attacker who can heap-groom the kmalloc-128 slab to cause cross-object reuse of a freed hci_pcb), the unlocked walk-vs-free is a genuine UAF race, exactly as the finding describes. The finding's severity (Medium, CVSS AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) is appropriate.

Exploit chain

This is a TOCTOU/UAF primitive, not a deterministic write. To convert to uid=0 an attacker would need to:

1. Groom the kmalloc-128 slab so that the kfree(pcb, M_PCB) in hci_sdetach is immediately followed by an attacker-controlled allocation of the same bucket that places forged content at the hp_socket offset (0) — overwriting the dangling hp_socket pointer with a pointer to a victim struct socket/struct ucred-bearing object (no SMAP, so userspace addresses work; no SMEP, so a userspace ops vector is executable from kernel context).
2. Time the hci_mtap walk so it reads the forged hp_socket and calls sbappendaddr(&pcb->hp_socket->so_rcv.sb, ...) / sorwakeup(pcb->hp_socket) on it.

This requires: (a) a populated hci_unit_list (a real or emulated BT controller — absent on this guest), and (b) a heap-grooming spray of sizeof(struct hci_pcb)=104 (→ kmalloc-128 bucket) with attacker-shaped content landing on hp_socket at offset 0. The slab poison limitation documented above ALSO blocks the natural panic, so it simultaneously helps an attacker (the bug is silent on INVARIANTS-ON GENERIC, not noisy) and hurts the reproducer (we can't easily demonstrate the fault without the heap-grooming step).

Outcome: NOT ACHIEVED on this guest. The valid hard blocker is "the vulnerable code path is unreachable at runtime on this guest AND no harness that respects the realism rules can exercise it end-to-end from an unprivileged user" — the hci_unit_list is empty (no BT controller, no loadable virtual BT driver), so hci_mtap never runs from a real input path, and the heap-grooming escalation requires that path to be live to shape the dangling pointer. The kld harness can drive hci_mtap but cannot realistically demonstrate the heap-groomed uid=0 chain because step (1) above would require either a real BT controller's packet input timing (absent) or a circular kldload-based re-claimer (forbidden by the bright-line rule for uid=0 claims). This is a Medium-severity latent UAF that needs BT HW (or an emulated BT device) plus patient heap grooming to land — reported as corruption (latent UAF confirmed at source level), not uid=0.

PoC changes

• poc_race.c — original reviewer PoC had multiple errors that prevented compilation (btr_enabled doesn't exist — the field is btr_flags & BTF_UP; SO_HCI_OMIT_XMIT doesn't exist on DragonFly; PF_BLUETOOTH was hard-coded to 31 instead of 33; SOCK_RAW was hard-coded to 1 instead of 3). Rewrote it as a dense driver: 4 "churner" threads each keep 64 HCI sockets open and continuously close+reopen one slot, plus 2 "spammer" threads that open/close as fast as possible. This densely populates the global hci_pcb list and drives millions of hci_sattach/hci_sdetach cycles per second.
• df0586_harness.c — new kld module that calls hci_mtap() directly from a kernel thread on cpu1 with a synthesized struct hci_unit and mbuf. This stands in for the missing BT-radio input path (sys/netbt/hci_unit.c:494), since the guest has no controller and hci_send returns ENETDOWN before reaching hci_output_cmd. Has two modes: mode=0 self-contained (walker + killer threads, killer bypasses the lock — for stress), mode=1 walker-only (default; lets the userspace driver exercise the real hci_sattach/hci_sdetach and is compatible with the patched kernel's lock).
• build.sh, run.sh — exact reproducible build/run commands.
• fix.diff — a git apply-able minimal fix authored post-verification.
• Full build.log, run.log, fix_build.log saved.

Fix validation (Phase 8)

fix_status: not_testable (with caveat). Concretely:

• fix.diff applies cleanly to /usr/src: patch -p1 --forward ⇒ all 5 hunks succeeded (Hunk #1..5 succeeded).
• fix.diff compiles cleanly: make -j6 nativekernel KERNCONF=X86_64_GENERIC ⇒ NK_DONE rc=0 (full log in fix_build.log).
• Patched kernel #1 boots: kern.version reports DragonFly 6.5-DEVELOPMENT #1: Wed Jul 8 16:14:16 UTC 2026.
• Patched netbt.ko has the new lock symbol: nm netbt.ko | grep hci_pcb_lock ⇒ 00000000000011e0 D hci_pcb_lock (the unpatched module has no such symbol).
• Runtime panic before/after comparison: NOT FEASIBLE on this guest. The unlocked-walk-vs-free race doesn't reliably fault on INVARIANTS-ON GENERIC without a populated hci_unit_list (the slab poison zone stops at byte 64; hp_next lives at byte 88). The harness performed 3.3B+ walker cycles against 4M+ socket open/close cycles on the unpatched kernel with no panic, so there is no "before panic" marker to compare against. The fix is therefore validated at the source/compile/boot level (applies, compiles, links, boots, adds the lock) and traced line-by-line to close the cited code path (LK_EXCLUSIVE around LIST_INSERT_HEAD and LIST_REMOVE, LK_SHARED around the LIST_FOREACH body), but a runtime before/after panic comparison requires BT hardware this guest lacks.

Recommended fix

The fix.diff in this folder adds a dedicated struct lock hci_pcb_lock initialised at file scope and acquires it: - LK_EXCLUSIVE around hci_sattach's LIST_INSERT_HEAD (replacing the inadequate crit_enter()/crit_exit()), - LK_EXCLUSIVE around hci_sdetach's LIST_REMOVE, - LK_SHARED around the entire hci_mtap LIST_FOREACH body.

This matches the finding's proposal (and the rest of netbt, which already uses a struct lock for unit->hci_devlock). The finding's proposed diff additionally wraps hci_cmdwait_flush in hci_pcb_lock, but that walk is of hci_unit_list, not hci_pcb — a different (real) bug that needs its own hci_unit_list lock. My fix.diff is tighter: it only addresses the hci_pcb-list race that is DF-0586's scope. It supersedes the finding's proposal by dropping the misplaced hci_cmdwait_flush hunk while keeping the four essential hci_pcb hunks.

Files in this folder

• df0586_harness.c — kld harness driving hci_mtap from a kernel thread (stands in for the missing BT-radio input path).
• poc_race.c — userspace dense driver (churner + spammer threads).
• build.sh, run.sh — exact build/run commands.
• fix.diff — git-apply-able minimal fix.
• build.log, run.log, run.2.log, run.3.log — full untrimmed logs.
• fix_build.log — full untrimmed make nativekernel output.
• env.txt — guest environment for the runs.
• manifest.json — artifact catalog.