DF-2976 — VERDICT

status: reproduced / impact: dos (unbounded kernel heap leak by unprivileged user) / confidence: certain

What was run

race_attach.c (this pack) on the DF 6.5-DEVELOPMENT guest (stock INVARIANTS kernel #0, Thu Jul 2 06:02:54 UTC 2026), as unprivileged uid 1001 (maxx), with accf_http.ko loaded by root. Two runs:

• 3000 iterations × 6 threads → 117 iterations where ≥2 threads returned success; vmstat -m M_ACCF in-use went 1 → 118 (+117 × 24 B = 2.79 K).
• 5000 iterations × 8 threads → 178 wins; in-use 118 → 299 (+181 chunks).

The +chunks ≈ #wins match is the decisive evidence: each race win orphans exactly one kmalloc(sizeof(struct so_accf), M_ACCF, M_WAITOK|M_ZERO) (uipc_socket.c:2042) that nothing ever frees — the socket only remembers the last pointer stored at uipc_socket.c:2061, and the clear path (do_setopt_accept_filter(so, NULL), uipc_socket.c:2009-2022, reached only via sodealloc at uipc_socket.c:321) frees only the current one.

Why it is a bug

The whole window between the af != NULL check (uipc_socket.c:2026, value read at function entry line 1999) and so->so_accf = af (2061) contains two M_WAITOK (sleepable) allocations — kmalloc of accept_filter_arg (2031) and of struct so_accf (2042) — and no lock: kern_setsockopt() (uipc_syscalls.c :1213-1233) invokes sosetopt() (uipc_socket.c:2128) directly on the syscall thread; there is no protocol-thread dispatch for SOL_SOCKET options. An unprivileged user with two threads on a dup'd/listener fd wins the race at a measurable rate (~24 wins/s with 8 threads here).

Impact ceiling

Unprivileged, unbounded kernel heap exhaustion (M_ACCF zone): ~800 B/s per process single-guest measurement; scales with parallelism (processes × threads). Eventual kmem exhaustion → allocator failure/panic. Rate is slow, so this is a Low-severity resource-exhaustion DoS, not a fast kill.

Exploit chain

none (resource leak; no memory-safety violation — loser pointer is orphaned, never freed-twice, never read after free).

Fix direction (validated as part of the DF-2975 pack's kernel: NOT included

in DF-2975/fix.diff, which only fixes the registry lifetime)

Publish the attach with an atomic compare-and-swap so only one racer wins:

--- a/sys/kern/uipc_socket.c
+++ b/sys/kern/uipc_socket.c
@@  af->so_accept_filter = afp;
-   so->so_accf = af;
+   if (!atomic_cmpset_ptr((volatile uintptr_t *)&so->so_accf,
+                  (uintptr_t)NULL, (uintptr_t)af)) {
+       /* another thread attached concurrently: back off */
+       if (af->so_accept_filter_str != NULL)
+           kfree(af->so_accept_filter_str, M_ACCF);
+       kfree(af, M_ACCF);
+       accept_filt_release(afp);
+       error = EINVAL;
+       goto out;
+   }
    so->so_options |= SO_ACCEPTFILTER;

This keeps the fix local (no lock-order interaction with pool tokens).