# DF-2694 VERDICT

## Status: REPRODUCED (unprivileged local kernel panic; race-class UAF)

Two independent panics captured on the stock INVARIANTS guest kernel, both
from an unprivileged user (`maxx`, uid 1001), both exactly at the lines
predicted by source analysis:

1. **TCP path** — `panic: assertion "m" failed in sorecvtcp at
   /usr/src/sys/kern/uipc_socket.c:1852` (see `panic.txt`, `run.log`).
   Trigger: `/tmp/poc_race 40 3000 3000 0`.
2. **AF_UNIX path** (generic `soreceive`) — `panic: assertion "sb->sb_mb ==
   m" failed in sbunlinkmbuf at /usr/src/sys/kern/uipc_sockbuf.c:552`
   (see `panic2.txt`). Trigger: `/tmp/poc_race 60 200 500 1`.

## Root cause (line-accurate)

* `soshutdown()` intentionally skips `ssb_lock` for the read side
  (`sys/kern/uipc_socket.c:1953-1957`) and calls `sorflush()`.
* `sorflush()` (`uipc_socket.c:1963-1991`) takes only `so_rcv.ssb_token`,
  snapshots the sockbuf (`asb = *ssb`), `bzero()`s `ssb->sb`, and frees the
  whole chain: `ssb_release(&asb)` → `sbflush()` (`uipc_socket2.c:754-760`)
  → `sbdrop()` (`uipc_sockbuf.c:473-508`) → `m_freem()`.
* A receive is in one of two states w.r.t. that token:
  * `sorecvtcp()` explicitly drops it around the copy loop
    (`uipc_socket.c:1756/1758`), marking the chain `M_SOLOCKED`
    (`:1746-1753`) — but `M_SOLOCKED` is only honored by `sbcompress()`
    (`uipc_sockbuf.c:376`), **never on the flush/free path**.
  * generic `soreceive()` holds it across the loop (`:1322`).
* **In DragonFly, a thread that blocks releases all its lwkt tokens**
  (`lwkt_switch()` → `lwkt_relalltokens()`, `sys/kern/lwkt_thread.c`).
  The moment either copier sleeps inside `uiomove()` — e.g. a swap-in or
  file-I/O page fault on the user receive buffer — its token protection is
  gone and `sorflush()` frees/zeroes the chain underneath it:
  * the copier then reads freed mbufs (`m->m_next == NULL` after `m_free()`)
    and copies freed-cluster contents into the user buffer (UAF read), and
  * the post-loop bookkeeping trips over the zeroed sockbuf:
    `sorecvtcp` at `KKASSERT(m)` (`:1851-1852`), `soreceive` at
    `sbunlinkmbuf`'s `KKASSERT(sb->sb_mb == m)` (`uipc_sockbuf.c:552`).

## Why the PoC needs the "pig"

The window exists only while the copier is *blocked*. With resident receive
windows the copy never sleeps, the token stays (effectively) held, and
`shutdown(SHUT_RD)` serializes harmlessly behind the copy — hundreds of
sweep rounds produced zero hits until the receive windows were forced out to
swap, making every `uiomove()` fault a sleeping `vm_fault`. This also frames
real-world reachability: any process that `recv()`s into swapped/cold pages
(an HTTP server under memory pressure is the canonical case) races any other
thread's `shutdown(SHUT_RD)`/`SO_RCVSHUTDOWN`-style flush.

## Impact assessment

* **Reproduced**: reliable unprivileged local kernel panic (DoS). Both the
  TCP (`sorecvtcp`) and generic (`soreceive`) receive paths are affected;
  AF_UNIX and UDP sockets use the generic path.
* **UAF read**: after the flush the copier does `uiomove()` out of freed
  clusters. On the INVARIANTS kernel the subsequent assertion fires inside
  the same syscall, so those bytes cannot be harvested from userspace.
  No info leak was demonstrated on this kernel.
* **Non-INVARIANTS (production) kernels**: the generic path has no assert;
  `sbunlinkmbuf()` (`uipc_sockbuf.c:548-578`) then executes
  `sb->sb_mb = m->m_nextpkt` with `m` freed — writing a stale pointer into
  live sockbuf state and doing `sbfree()` accounting on freed memory.
  That is sockbuf corruption with (objcache-reuse) attacker-influenced
  contents — assessed as worse than the panic, though not demonstrated here
  (would require a non-INVARIANTS build).
* No uid=0 escalation chain: the primitive is a free-under-reader of the
  victim's own socket data; the hard blocker on this kernel is the
  in-syscall assertion (INVARIANTS) / NULL-or-stale-pointer store whose
  value the attacker does not control precisely. Documented as a hard
  blocker for escalation on the audited build.

## Fix validation

`fix.diff` makes `sorflush()`, after `socantrcvmore()`, poll (bounded,
1 tick, ≤1000 iterations) until no `M_SOLOCKED` mbufs remain in the sockbuf
before snapshotting/zeroing/freeing it. Copiers finish autonomously
(their marked mbufs are untouched; readers blocked in `ssb_wait` were
already woken by `socantrcvmore()`, so `MSG_WAITALL` loops terminate and
cannot deadlock the flusher).

Baseline (stock kernel): both PoC modes panic the guest.
Patched kernel (`make nativekernel` with `fix.diff` in-guest): both PoC
modes run to completion (`done: N rounds, 0 marker leaks`), guest stays up,
see `fix_build.log` / `fix_run.log`.

## Classification

* severity: High — race (CWE-362) → UAF (CWE-416) reachable unprivileged
  from both TCP and AF_UNIX/UDP; reliable panic; potential sockbuf pointer
  corruption on production builds.
* verdict.json impact: `panic` (that is what was reproduced end-to-end).