soisconnected derefs head->so_accf based on inherited child SO_ACCEPTFILTER flag (NULL-deref/UAF race)

Summary

In soisconnected(), the test (so->so_options & SO_ACCEPTFILTER) != 0 (uipc_socket2.c:253) reads the child's options flag, which was inherited from head at sonewconn_faddr time (so->so_options = head->so_options &~ SO_ACCEPTCONN, :376 — set without the pool token). The branch then dereferences head->so_accf->so_accept_filter->accf_callback (:254) without re-checking that head still has an installed filter.

If, between sonewconn_faddr() and the later soisconnected() call on the in-progress child, the listening socket's owner removes the accept filter via setsockopt(SOL_SOCKET, SO_ACCEPTFILTER, NULL), do_setopt_accept_filter() frees head->so_accf and sets it to NULL (uipc_socket.c:2018-2019). The child still carries the inherited flag, so the deref at :254 hits NULL (kernel panic, local DoS) — or, in the kfree()-to-NULL-assignment window, a dangling pointer (UAF).

The head pool token is held at :244, but it is unclear whether the setsockopt removal path takes the same token. Listen sockets are explicitly not per-CPU (comment at :263-265), so cross-CPU races are plausible.

Marked speculative because the dispatch/locking model may serialize this in practice; a maintainer should confirm.

Recommended fix

Re-check head->so_accf != NULL under the pool token, and test the head's flag rather than the child's:

--- a/sys/kern/uipc_socket2.c
+++ b/sys/kern/uipc_socket2.c
@@ if (head && (so->so_state & SS_INCOMP)) {
-   if ((so->so_options & SO_ACCEPTFILTER) != 0) {
+   if ((head->so_options & SO_ACCEPTFILTER) != 0 && head->so_accf != NULL) {
        so->so_upcall = head->so_accf->so_accept_filter->accf_callback;

Additionally, have do_setopt_accept_filter() take the head pool token when clearing so_accf so the read is serialized against removal.

Timeline

• 2026-06-30 Discovered during automated file-by-file audit of sys/kern/uipc_socket2.c.
• pending Reported to DragonFlyBSD security contact.