DF-2561 PoC — soisconnected vs do_setopt_accept_filter race

Verdict: NOT REPRODUCED — FALSE POSITIVE (see VERDICT.md)

What this tests

The finding claims soisconnected (sys/kern/uipc_socket2.c:254) dereferences head->so_accf without a NULL check and without a lock that interlocks with do_setopt_accept_filter, which a concurrent setsockopt could use to free+NULL so_accf.

Preconditions

• accf_data kernel module loaded (root setup: kldload accf_data).
• PoC itself runs as unprivileged maxx.

Reproduce

./build.sh
# as root on guest:  kldload accf_data
./run.sh

Expected (bug present)

Kernel panic: NULL deref, UAF, or INVARIANTS KKASSERT in soisconnected / do_setopt_accept_filter under concurrent connect + setsockopt-clear / listener-close stress.

Actual (on 6.5-DEVELOPMENT #0, INVARIANTS ON)

No crash. Across three stress variants:

Why it's safe (one-line)

The lwkt_getpooltoken(head) acquired at uipc_socket2.c:244 (held across the deref) mutually excludes soqflush (uipc_socket.c:348) which gates the only so_accf-freeing path (sodealloc → do_setopt_accept_filter(so, NULL)). And a user setsockopt cannot free so_accf regardless — do_setopt_accept_filter returns EINVAL if a filter already exists (uipc_socket.c:2026-2028).

Full analysis in VERDICT.md.

DF-2561 — soisconnected vs do_setopt_accept_filter NULL-deref/UAF race

Verdict: NOT REPRODUCED — FALSE POSITIVE

The race the finding describes does not exist on this kernel (6.5-DEVELOPMENT #0, the audited master DEV tree, INVARIANTS ON). The finding's premise — that "a concurrent setsockopt to clear/change the accept filter on the listener frees head->so_accf" — is wrong on two independent counts, either of which alone closes the bug:

1. A user-driven setsockopt(SO_ACCEPTFILTER) cannot clear or change an existing accept filter. do_setopt_accept_filter() returns EINVAL as soon as it sees the listener already has a filter (sys/kern/uipc_socket.c:2026-2028: if (af != NULL) { error = EINVAL; goto out; }). There is no code path from setsockopt that reaches the kfree(af) / so->so_accf = NULL block at sys/kern/uipc_socket.c:2018-2019; that block runs only when sopt == NULL, which is an internal call exclusively from sodealloc() (sys/kern/uipc_socket.c:320-321, listener teardown). Empirically confirmed: 70,520,847 setsockopt(SO_ACCEPTFILTER) clear/change attempts (empty-name, same-name re-set, different-name change, null-prefixed) on a live listener produced 0 successes, 69,896,707 EINVAL, 0 ENOENT — so_accf was never freed or modified via the syscall surface the finding names.

2. Even the only real free path (listener close → sodealloc → do_setopt_accept_filter(so, NULL)) is interlocked against soisconnected by the lwkt pool token. soisconnected holds lwkt_getpooltoken(head) (sys/kern/uipc_socket2.c:244) across the head->so_accf dereference at uipc_socket2.c:254-255. sodealloc (the sole caller of do_setopt_accept_filter(so, NULL)) is reached only from sofree (uipc_socket.c:443), which for a listener calls soqflush(so) (uipc_socket.c:439) first — and soqflush acquires that exact same pool token (uipc_socket.c:348: lwkt_getpooltoken(so)) before doing anything. So while soisconnected is dereferencing head->so_accf, the listener's teardown cannot proceed past soqflush, and therefore cannot reach sodealloc → do_setopt_accept_filter → kfree(so_accf). The race window is closed by token mutual exclusion.

Empirically confirmed: 82,011 listener close+recreate rotations (each driving sofree → soqflush → sodealloc → do_setopt_accept_filter → kfree(so_accf)) interleaved with 5,025,027 connections (each driving sonewconn → soisconnected → deref head->so_accf) produced no panic, no assert, no corruption. The guest stayed up throughout.

Mechanism walkthrough (why it's safe)

Thread A (protocol thread, e.g. tcp netisr):          Thread B (user close):
  soisconnected(child)                                  soclose(listener)
    head = child->so_head  [non-NULL]                    ... drop refs, pru_detach ...
    lwkt_getpooltoken(head)        <<-- ACQUIRE -->>     sofree(listener)
      deref head->so_accf                                 soqflush(listener)
        (lines 254-255: read accf_callback/arg)             lwkt_getpooltoken(so)  *** BLOCKS ***
      ... set up upcall ...                                 (waits for soisconnected to release)
    lwkt_relpooltoken(head)       <<-- RELEASE -->>     ... soqflush proceeds: abort all queued children
                                                         sodealloc(listener)
                                                           do_setopt_accept_filter(so, NULL)
                                                             kfree(so->so_accf)   <-- NOW safe:
                                                             so->so_accf = NULL       no reader left

The pool token is the same object in both columns because lwkt_getpooltoken is keyed by the socket pointer (sys/kern/lwkt_token.c:816-823 -> _lwkt_token_pool_lookup(ptr)), so getpooltoken(head) and getpooltoken(so) (where so == head == the listener) serialize across all CPUs. There is no blocking call inside the soisconnected critical section (uipc_socket2.c:254-259) that would degrade the token, so the token is held continuously across the deref. (The accf_data upcall sohasdata does not block either.)

Why the finding looked plausible (and where the reviewer went wrong)

• The code at uipc_socket2.c:254 does indeed dereference head->so_accf with no NULL check — that part of the observation is accurate. A NULL check would be cheap defense-in-depth.
• The reviewer assumed do_setopt_accept_filter could be driven by a user setsockopt to free so_accf. It cannot: the user path returns EINVAL if a filter already exists (uipc_socket.c:2026-2028). The kfree(so->so_accf) block is reachable only from sodealloc (internal teardown), which the reviewer did not trace.
• The reviewer did not account for the lwkt_getpooltoken(head) acquired at uipc_socket2.c:244 (held across the deref) mutually excluding soqflush (uipc_socket.c:348) which gates sodealloc.

PoC variants run (all clean, no panic)

Each variant loads accf_data.ko (root setup — kldload accf_data) and runs as unprivileged maxx. The filter name is "dataready". Children inherit SO_ACCEPTFILTER at sonewconn (uipc_socket2.c:376) and soisconnected runs the accept-filter branch on every connection.

Impact

None. No memory corruption, no NULL deref, no UAF, no DoS. The finding is a false positive.

Recommended fix

No code change needed: false-positive. The lwkt_getpooltoken(head) acquired at sys/kern/uipc_socket2.c:244 (held across the deref at lines 254-255) mutually excludes soqflush (sys/kern/uipc_socket.c:348) which gates the only path that frees so_accf (sodealloc → do_setopt_accept_filter(so, NULL) at uipc_socket.c:320-321). A user-driven setsockopt cannot free so_accf regardless (uipc_socket.c:2026-2028 returns EINVAL).

A NULL-check on head->so_accf at uipc_socket2.c:254 would be cheap defense-in-depth but is not a security fix — no path leads to it being NULL while the flag check at line 253 passes under the token.