DF-3373 — connect(2)/listen(2) TOCTOU links one inpcb into two TCP hashes

Root cause

The socket-layer guards are check-then-act with no token and no handler-side re-check:

• soconnect() reads SO_ACCEPTCONN (uipc_socket.c:690) and SS_ISCONNECTED|SS_ISCONNECTING (:698) on the caller's thread.
• solisten() reads SS_ISCONNECTED|SS_ISCONNECTING (uipc_socket.c:332-333) and only then stores SO_ACCEPTCONN (:337) and queues the pru_listen message.
• With the default kern.ipc.soconnect_async=1, SS_ISCONNECTING is stored by tcp_usr_preconnect (tcp_usrreq.c:970), i.e. after soconnect's checks and after a kmalloc — a real window on the connector thread.

Neither tcp_usr_listen (guards only TF_LISTEN and inp_lport == 0) nor tcp_usr_connect/tcp_connect (guards only inp_faddr != ANY) re-checks the opposite state. Both orders of the two serialized pru messages therefore complete and the same inpcb gets linked into both the wildcard hash and the connection hash:

• listen-msg first: pcb becomes listener (INP_WILDCARD, in_pcb.c:2283); tcp_connect then proceeds — reproduced panic at in_pcbunlink_flags ("already linked", in_pcb.c:311) via tcp_connect's migration unlink (tcp_usrreq.c:1235); without INVARIANTS it would reach in_pcbinsconnhash (in_pcb.c:1905) and gain INP_CONNECTED while INP_WILDCARD.
• connect-msg first: pcb enters SYN_SENT (INP_CONNECTED, in_pcb.c:1906); tcp_usr_listen then migrates/inserts into the wildcard hash (tcp_usrreq.c:461/513, asserts :507 or in_pcb.c:2289).

Production-kernel impact (why this is memory corruption, not just DoS)

in_pcb_rmhash (in_pcb.c:2381-2383) removes only one membership (if (INP_WILDCARD) ... else if (INP_CONNECTED) ...). Teardown of the dual-member pcb leaves the other hash bucket pointing at freed memory; subsequent in_pcblookup_hash walks dereference the freed inpcb (use-after-free on a 4-tuple the attacker controls). Additionally the listening socket is simultaneously a connected 4-tuple, so incoming connection attempts can be matched/accepted against the wrong state.

Reproduction (guest: DragonFly 6.5-DEVELOPMENT #0, INVARIANTS)

listen_connect_race.c: thread A loops {socket(); publish fd; connect(10.0.2.2:1) (nonblocking)}, thread B spins listen(fd, 1). Unprivileged (maxx, uid 1001).

Reproduced twice from clean with-src snapshots, both within ≤ 45 s:

panic: already linked
cpuid = 0
in_pcbunlink_flags() at in_pcbunlink_flags+0x5e
in_pcbunlink_flags() at in_pcbunlink_flags+0x5e
tcp_connect() at tcp_connect+0x56c
netmsg_service_loop() at netmsg_service_loop+0xe9
Debugger("panic")

(panic.txt / boot_panic.log; ssh session dies, vm.sh status → down.)

Fix

fix.diff — handler-side, race-free state guards (pru messages are serialized per socket):

• tcp_usr_listen/tcp6_usr_listen: reject when tp->t_state != TCPS_CLOSED || (so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) || inp->inp_fport != 0 || inp->inp_pcbinfo == NULL (last term catches a connect message that is mid-migration between netisrs).
• tcp_connect/tcp6_connect: reject when TF_LISTEN (covers both the first entry and the PRUC_RECONNECT re-entry after forwarding).

Fix validation

Baseline panic reproduced twice on stock; after applying fix.diff to the guest /usr/src, make nativekernel KERNCONF=X86_64_GENERIC, reboot, and re-running the identical hammer (same duration, longer second run) the guest survived with clean EOPNOTSUPP/EINVAL returns — see run_fixed.log, fix_results in verdict.json.

Build / run

cc -O2 -pthread -o listen_connect_race listen_connect_race.c
./listen_connect_race 45        # stock kernel: panics within seconds

DF-3373 VERDICT — connect(2)/listen(2) TOCTOU → single inpcb in two TCP hashes

Reproduced? YES — kernel panic, twice, unprivileged, ≤45 s per attempt

• Guest: DragonFly 6.5-DEVELOPMENT #0 (stock INVARIANTS X86_64_GENERIC, Jul 2 2026 build), 6 vCPUs, user maxx (uid 1001).
• PoC: listen_connect_race.c — thread A: fresh socket() + nonblocking connect(10.0.2.2:1) in a loop; thread B: listen(fd,1) spin.
• Baseline run 1: panic at ~≤45 s (ssh session died; vm.sh status → down). Baseline run 2 (after vm.sh reset with-src, fresh disk): identical panic. Signature both times:

panic: already linked
cpuid = 0
in_pcbunlink_flags() at in_pcbunlink_flags+0x5e
tcp_connect() at tcp_connect+0x56c
netmsg_service_loop() at netmsg_service_loop+0xe9
Debugger("panic")

(panic.txt, boot_panic.log; serial console captured via vm.sh log.)

Mechanism (proven on-guest, matches source)

solisten (uipc_socket.c:332) and soconnect (uipc_socket.c:690,698) guard with plain check-then-act flag reads; with kern.ipc.soconnect_async=1 (default, verified) SS_ISCONNECTING is only stored by tcp_usr_preconnect (tcp_usrreq.c:970) — after soconnect's checks and after a kmalloc in so_pru_connect_async (uipc_msg.c:214). A listen(2) whose flag read slips into that window queues a pru_listen message that tcp_usr_listen (guards: only TF_LISTEN and inp_lport == 0, tcp_usrreq.c:481-488) happily processes against the racing connect.

Reproduced interleaving: listen message first → inpcb wildcard-hashed (INP_WILDCARD, in_pcb.c:2290) → tcp_connect's hashport migration in_pcbunlink (tcp_usrreq.c:1235) → KASSERT (inp_flags & (INP_WILDCARD|INP_CONNECTED)) == 0 (in_pcb.c:311) → panic: already linked.

The mirrored interleaving (connect message first) is equally fatal: tcp_usr_listen would hit ASSERT_INP_NOTINHASH (tcp_usrreq.c:507 / in_pcb.c:2289) or in_pcbunlink again.

Impact

• This INVARIANTS kernel: reliable local unprivileged panic (DoS) — hit within ≤45 s of hammering, twice from clean snapshots.
• Production (non-INVARIANTS) kernels: kernel memory corruption. The same interleaving links one inpcb into BOTH the wildcard hash (via inpcontainers, in_pcb.c:2272-2274) and the connection hash (inp_hash, in_pcb.c:1913), setting INP_WILDCARD|INP_CONNECTED. in_pcb_rmhash (in_pcb.c:2381-2383) removes only ONE membership (wildcard wins), so teardown leaves the connhash bucket holding a pointer to the freed inpcb; any later packet matching that 4-tuple walks it (in_pcblookup_hash) → use-after-free with attacker-chosen tuple. Additionally the hybrid socket serves both listener and client lookups simultaneously. (Not demoable on this INVARIANTS guest: every dual-membership path asserts first — documented from source.)

Exploit chain

unpriv user → 2-thread connect/listen race (≤45 s) → inpcb linked into wildcard+conn hashes → INVARIANTS: panic / production: one-sided hash removal at close → dangling connhash entry → in_pcblookup_hash UAF on attacker-chosen 4-tuple (memory-corruption ceiling; not pursued to uid=0 on this INVARIANTS guest).

Fix validation (mandatory for reproduced memcorrupt) — FIXED

fix.diff (v3) adds race-free handler-side guards:

• tcp_usr_listen/tcp6_usr_listen: TF_LISTEN early-out (backlog update) first; then reject when t_state != TCPS_CLOSED || SS_ISCONNECTED|SS_ISCONNECTING || inp_fport != 0 || inp_pcbinfo == NULL (PRUL_RELINK re-entry exempt), and undo solisten's SO_ACCEPTCONN under so_rcv.ssb_token so tcp_input (tcp_input.c:950) and soclose never see a "listener" that isn't one.
• tcp_connect/tcp6_connect: reject TF_LISTEN with EOPNOTSUPP (covers first entry and PRUC_RECONNECT re-entry) without soisdisconnected() on the listener (children inherit parent state, uipc_socket2.c:383).

Two earlier fix revisions crashed under the same hammer and were diagnosed and corrected (v1: guards but no SO_ACCEPTCONN undo → NULL deref in in_pcbdetach via tcp_input's listener branch; v2: guard ordered before the TF_LISTEN early-out → re-listen cleared SO_ACCEPTCONN on a live listener). v3 survived.

• Baseline (stock): panic ≤ 45 s, twice — panic.txt.
• Patched kernel #1: Fri Sep 11 17:25:03 UTC 2026 (make nativekernel/installkernel in guest, fix.diff applied to /usr/src): run_fixed.log — 377,194 connect iters / 45 s, 140,024 EOPNOTSUPP rejections, 162,885 successful listens, SURVIVED; run_fixed.2.log — 1,024,176 iters / 120 s, SURVIVED. ssh (TCP) fully functional throughout.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.