# 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

```sh
./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:

| variant | hammer | iterations | result |
|---|---|---|---|
| `df2561`  | close-rotator + acceptor + 8 conn | 68K rot × 3.9M conn | NO_CRASH |
| `df2561b` | aggressive close-rot, no acceptor, 16 conn | 82K rot × 5.0M conn | NO_CRASH |
| `df2561c` | setsockopt-clear racing w/ connectors | 70.5M attempts, 0 ok / 69.9M EINVAL | NO_CRASH |

## 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`.