# VERDICT — DF-2702 (recvmsg MSG_PEEK skips unp_externalize → kernel file-pointer leak)

**status: reproduced** (impact: leak, confidence: certain)

## Root cause

AF_UNIX SCM_RIGHTS travel in two forms:

* **internalized** — while queued in `so_rcv`: a 16-byte `cmsghdr` followed by
  N raw `struct file *` kernel pointers. Written by `unp_internalize()`
  (sys/kern/uipc_usrreq.c:1817-1825), which sets
  `cm->cmsg_len = CMSG_LEN(oldfds * sizeof(struct file *))`.
* **externalized** — when delivered: `unp_externalize()`
  (sys/kern/uipc_usrreq.c:1543-1633) replaces each pointer with an allocated
  fd number in the receiver's fd table and rewrites
  `cm->cmsg_len = CMSG_LEN(newfds * sizeof(int))` (uipc_usrreq.c:1629).

`soreceive()` runs the externalize step only on the **consume** path
(sys/kern/uipc_socket.c:1426-1437). The `MSG_PEEK` branch right above it
(sys/kern/uipc_socket.c:1422-1425) simply `m_copym()`s the control mbuf and
appends the copy to the `*controlp` chain:

```c
if (flags & MSG_PEEK) {
        if (controlp)
                *controlp = m_copym(m, 0, m->m_len, M_NOWAIT);
        m = m->m_next;      /* XXX race */
}
```

`kern_recvmsg()` (sys/kern/uipc_syscalls.c:1172-1189) then `copyout()`s
`m->m_len` bytes of that copy — i.e. the raw `struct file *` values — into the
user's control buffer. No externalize, no sanitization, no privileges needed.

(You cannot "just externalize the copy": `unp_externalize()` drops the
in-flight rights references (`unp_del_right()` + `fdrop()`,
uipc_usrreq.c:1666-1667) which the still-queued original message owns — that
would corrupt `f_msgcount`/`unp_rights`. Hence the fix returns no rights
control on peek; see fix.diff.)

## Reproduction (guest DragonFly 6.5-DEVELOPMENT #0, X86_64_GENERIC, uid=1001)

`./peek_rights_leak` (see run.log):

* sendmsg passes 2 fds over an `AF_UNIX` `SOCK_STREAM` socketpair with user
  `cmsg_len = CMSG_LEN(2*4) = 24`.
* PEEK #0 and PEEK #1 (same queued message) return `controllen=32`,
  `cmsg_len=32 = CMSG_LEN(2*8)`, and slots
  `0xfffff801167ffd80`, `0xfffff801167ffe80` — two kernel heap pointers
  (0x100 apart, same `struct file` slab zone). Identical across both peeks.
* REAL recvmsg of the same message returns `cmsg_len=24` and fds 6,7 — the
  consume path externalizes correctly, proving the peek copy is the anomaly.

`./dgram_peek` (run.2.log): SOCK_DGRAM leaks too:
`cmsg_len=24 = CMSG_LEN(1*8)`, `data0=0xfffff801167e5500`.

Across runs the leaked values always fall in the kernel virtual range
(`0xfffff801xxxxxxxx` on this kernel) and vary between processes — 4/4
observations matched kernel-memory pattern (leak criteria ≥3 runs satisfied).

## Impact

Unprivileged disclosure of live kernel heap addresses (`struct file`
allocations). Defeats heap-layout randomization, gives an attacker the file
zone base, and turns separate heap-corruption primitives into reliable
exploits (slab grooming targets). No KASLR on many DFly deployments makes the
*address* less secret, but the leak also discloses per-object placement and
requires zero privileges.

Severity: Medium (kernleak bucket).
CVSS: 3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (5.5).

## Fix validation

`fix.diff` (sys/kern/uipc_socket.c, MSG_PEEK branch): do not hand unreplaced
SCM_RIGHTS control back on peek (non-rights control such as SCM_CREDS is still
peekable). Validated by in-guest `make nativekernel KERNCONF=X86_64_GENERIC`
build + install + reboot:

* baseline (stock #0 kernel): pointer leak as above (run.log, run.2.log)
* patched kernel: PEEK returns `controllen=0` (no control data, no kernel
  pointers); REAL recvmsg still returns fds 6,7 — fd passing fully functional
* see fix_validation.log, fix_build_excerpt.txt

## Negative space (what was checked and killed in uipc_usrreq.c itself)

* `unp_bind`/`unp_find_lockref` stack `buf[SOCK_MAXADDRLEN]` + `strncpy` with
  `sun_len`: `getsockaddr()` normalizes `sa->sa_len = len` and caps `len <=
  SOCK_MAXADDRLEN` (sys/kern/uipc_syscalls.c:1519-1528), so `namelen <= 253`
  and all copies stay in-bounds (uipc_usrreq.c:1141-1145, 2425-2431).
* `unp_pcblist` `bcopy(..., sun_len)` into `xu_addr`: the `xu_au`/`xu_cau`
  unions are 256 bytes (sys/sys/unpcb.h:115-124), `sun_len <= 255`. No
  overflow. (The uninit-stack aspect is known DF-2558.)
* control-mbuf forging: `kern_sendmsg` bounds `controllen` to
  `[sizeof(cmsghdr), MLEN]` and copies it into a single mbuf
  (sys/kern/uipc_syscalls.c:934-943); `unp_internalize` validates
  `cmsg_len ∈ [CMSG_LEN(0), m_len]` (uipc_usrreq.c:1723-1729, 1757-1759) and
  rewrites `m_len = CMSG_ALIGN(newlen)` (1810), so every kernel-side consumer
  (`unp_scan`, `unp_externalize`) sees a self-consistent first-cmsg. Trailing
  user bytes in the control buffer are never parsed by the kernel.
* unpcb lifetime vs. blocking token release: every syscall entry holds the
  fp (`holdsock`), and `soclose` (thus `uipc_detach` → `unp_drop` → kfree)
  runs only on the last `fdrop`, so a blocked `nlookup` inside
  `unp_find_lockref`/`unp_connect` cannot free the unpcb under the caller.
  `unp_reference()`/`unp_free()` pairs verified balanced on all paths
  (uipc_accept 368-371, uipc_peeraddr 518-521, uipc_rcvd 579-589, uipc_send
  671/717 and 758/792, unp_connect 1233/1278 + find_lockref/1284, unp_gc_process
  2127-2138).
* `unp_disconnect` peer-free race: freeing the peer requires disconnecting us
  first, which needs our pool token (uipc_usrreq.c:1365-1370, 2544-2548) —
  safe under token.
* `unp_gc` (new scheme): phase-1 DEAD marking can double-count
  `unp_unreachable` (uipc_usrreq.c:2114-2119 returns without UNPGC_SCANNED),
  but phase 2 re-validates `f_count == unp_msgcount` before collecting and
  the loop exits when no DEAD entries remain — overcount is benign (no
  OOB on `unref[]`, guarded by KASSERT at 2271-2279). Markers used for safe
  iteration; `SYSCTL_OUT`-blocking iteration in `unp_pcblist` is marker-safe.
* `cru2x()` bzeros the whole `xucred` (sys/kern/kern_prot.c:1237) — no leak
  via LOCAL_PEERCRED (uipc_usrreq.c:951).
* `soreceive` no-control-buffer receive of rights correctly disposes
  (`free_rights` → `dom_dispose`, sys/kern/uipc_socket.c:1608-1612).

Known findings not re-reported: DF-0010/2557 (uninit cmsgcred), DF-0011/2559
(sbcreatecontrol NULL panic), DF-2558 (pcblist stack leak), DF-2560
(ssb_appendcontrol failure rights leak), DF-2694 (sorflush UAF, receive paths).