DF-5806 — VERDICT

Status: reproduced (impact: dos — permanent, unkillable, unprivileged local DoS) Confidence: certain

Root cause (code-level, all path:line into sys/kern/uipc_socket.c unless noted)

soreceive() ends with a retry block:

1596  if (orig_resid == resid && orig_resid &&
1597      (flags & MSG_EOR) == 0 && (so->so_state & SS_CANTRCVMORE) == 0) {
1598          ssb_unlock(&so->so_rcv);
1599          goto restart;
1600  }

The restart re-acquires ssb_lock (1324) and re-runs the head-of-queue blocking check (1340-1346), then walks the record again. With MSG_PEEK set, nothing is ever consumed: the soname walk is a pure m = m->m_next (1413), control mbufs are only m_copym'd (1424-1425), and data mbufs are just advanced past (1504-1506). So a record that contributes zero bytes to the reader leaves orig_resid == resid forever and the loop never terminates. Critically it also never sleeps — the only tsleep paths (ssb_wait at 1388/1569) are guarded by the blocking condition at 1340-1346, which for the trigger records is always false (see below), so the thread spins in kernel mode holding one so_rcv token hold, and never reaches a signal-delivery point: kill -9 is ineffective.

Two unprivileged trigger shapes (both confirmed reachable by source analysis; variant 0 exercised on the guest):

1. AF_UNIX SOCK_STREAM, control-only record: - sosend explicitly allows zero-data-with-control sends (829-830: !(resid == 0 && clen != 0) bypass). - sosend builds top = a single 0-length mbuf (863-895). - uipc_send STREAM path appends [control][0-len data] via ssb_appendcontrol (sys/kern/uipc_usrreq.c:756-760). - AF_UNIX stream protosw has NO PR_ADDR (sys/kern/uipc_proto.c:53), so the orig_resid = 0 suppression at 1409 does not fire; recv() (not recvmsg) passes controlp == NULL, so the suppression at 1446-1449 does not fire either. - Blocking check can't sleep: ssb_cc = 24 (cmsg bytes) >= ssb_lowat (=1, set in soreserve, sys/kern/uipc_socket2.c:673-674), MSG_WAITALL not set → second conjunct false → dontblock directly.
2. AF_UNIX SOCK_SEQPACKET, plain zero-length datagram: - sbappendrecord explicitly "permits zero length records" (sys/kern/uipc_sockbuf.c:196-198). - PR_ATOMIC is set for seqpacket (uipc_proto.c:61-62) → the whole blocking condition at 1340-1346 is false whenever the queue head exists, even with cc == 0.

UDP / unix-dgram are NOT affected (PR_ADDR forces orig_resid = 0 at 1409); TCP (sorecvtcp) is not affected (sbcompress drops zero-length mbufs, so a TCP sockbuf head always has m_len >= 1, and its restart at 1926-1930 therefore always makes progress or sleeps). The parallel guard is still added there for robustness.

Guest reproduction (3 consecutive runs, fresh vm.sh reset with-src boots)

Run 1 (variant 0, 1 spinner): - spinner launched as unprivileged user maxx; parent returned. - the FIRST subsequent command (ps auxww over ssh) hung >120 s with zero output; every later ssh died with "Connection timed out during banner exchange" (TCP completes via qemu slirp; guest sshd never gets scheduled to send its banner). - vm.sh status → down (ssh probe) while the qemu process kept running.

Run 2 (variant 0, 1 spinner, observer pre-positioned): - a root observer running at realtime priority (rtprio 0) wrote ps snapshots to /dev/console; it froze mid-loop as soon as the wedge took hold (serial log captured in boot.log.excerpt). - ssh dead again.

Run 3 (variant 0, 1 spinner, timed probes): - guest wedged so fast that even the launching ssh session could not drain its output buffer before the spinner pinned the machine.

Observation mapping: unprivileged local user → guest-wide permanent denial of service; RUN/timeout behaviour matches the README's hang/loop expectation (probe timeouts, guest never recovers, VM must be power-cycled). Per the honest-status table this is status=reproduced / impact=dos.

Impact ceiling

Not memory corruption; no escalation path identified (the loop holds only the per-socket ssb token). But as a DoS it is maximal for the class: one syscall from any local user permanently removes the machine from service (all userland starves, network stacks keep answering at the netisr level, so the host looks half-alive), and the offending thread cannot be killed by any means short of reboot.

Fix

fix.diff (git-apply-able, validated on the guest): never take the zero-progress restart when MSG_PEEK is set — in soreceive() (1596-1600) and, defensively, in sorecvtcp() (1926-1930). A peek of a zero-byte record then returns a short read (0 bytes), which matches the non-spinning behavior of other BSD stacks. Non-PEEK behavior is unchanged: every restart still consumes at least the soname/control mbufs of the record it scanned, so no non-PEEK spin is possible.

Fix validation

Baseline (stock kernel, 3 runs): guest wedged within seconds (see run.log). Patched (guest /usr/src + fix.diff, nativekernel rebuild): see fix-run.log — the same PoC returns immediately, repeated peeks keep working, full 6-spinner barrage leaves the guest responsive (details in fix-run.log).

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.