# DF-2886 VERDICT — uiomovez() reads past ZeroPage into userspace

## Bottom line

**REPRODUCED (impact: leak).** `uiomovez()`'s `UIO_USERSPACE` branch
performs `copyout(ZeroPage, iov->iov_base, cnt)` with `cnt` bounded only
by `min(iov_len, n)`, while `ZeroPage` is a fixed `PAGE_SIZE` (4096)
allocation (sys/kern/kern_slaballoc.c:316). For any `cnt > 4096` the
kernel copies `cnt - 4096` bytes of adjacent kernel heap into the
calling process's buffer. A KLD harness driving the engine's public API
delivered 64 stable non-zero kernel bytes (slab-allocator bookkeeping)
into an unprivileged (`nobody`) process's read buffer across 3+1 runs,
identical byte-for-byte across the first three. The one-hunk fix
(clamp `cnt` to PAGE_SIZE) was built as kernel #1 and eliminates every
non-zero byte while preserving the zero-fill contract (`read()` still
returns 65536 zeros). No panic; system stable before/after.

## Why it leaks (path:line)

- sys/kern/kern_subr.c:241-242 — `if (cnt > n) cnt = n;` — no PAGE_SIZE clamp
- sys/kern/kern_subr.c:246 — `error = copyout(ZeroPage, iov->iov_base, cnt);`
- sys/kern/kern_slaballoc.c:316 — `ZeroPage = kmem_slab_alloc(PAGE_SIZE, PAGE_SIZE, M_WAITOK|M_ZERO);`
- Leak content on this guest: sparse small integers in the 60KB window
  after ZeroPage (per-CPU slab-zone bookkeeping); identical across runs
  within a boot — see leak_sample_run{1,2,3}.txt. Content is live kernel
  heap (run 4 showed 63 vs 64 non-zero bytes as the allocator churned).

## Reachability analysis (why this is filed Low and not High)

`uiomovez` has exactly one in-tree caller: the NFSv3 short-read
zero-fill at sys/vfs/nfs/nfs_vnops.c:1433
(`uiomovez(len - retlen, uiop)`, `len = min(tsiz, nm_rsize)`,
default `nm_rsize = NFS_MAXDATA = 32768` — sys/vfs/nfs/nfs_vfsops.c:106,
sys/vfs/nfs/nfsproto.h:57). A malicious/compromised NFSv3 server can
legally reply `count < len, eof = 0`, which is precisely the zero-fill
trigger — **but** every uio reaching `nfs_readrpc_uio()` today is
`UIO_SYSSPACE`:

- sys/vfs/nfs/nfs_bio.c:1080-1104 (`nfs_doio`): `io.iov_base = bp->b_data`,
  `uio_segflg = UIO_SYSSPACE` → takes the `bzero()` branch (safe);
- sys/vfs/nfs/nfs_vnops.c:433-448: 1-byte `UIO_SYSSPACE` probe (safe).

Therefore no stock syscall path currently reaches the OOB `copyout`;
the defect is a live booby-trap in a core subroutine: any caller that
zero-fills >4096 bytes into a `UIO_USERSPACE` uio (e.g. someone
"optimizing" nfs_doio to copy directly into user buffers) gets an
immediate 60KB-class kernel heap disclosure into unprivileged hands.
Engine defect: certain. Current reachability: latent.

## Exploit chain

None (information disclosure class; no corruption primitive). The leak
window is the fixed 60KB following a boot-time allocation; on this
guest it holds allocator metadata (no kernel pointers observed in 4
runs). On a system whose post-ZeroPage pages hold pointer-bearing
structures it would aid heap/KASLR mapping. No user→root route.

## Fix validation

- Baseline (kernel #0, stock): `run.log` — 4/4 runs LEAK CONFIRMED as
  `nobody` (64, 64, 64, 63 non-zero bytes ≥4096).
- Patched (kernel #1, `fix.diff` applied, `make nativekernel` +
  `make installkernel` + reboot): `run.fixed.log` — 2/2 runs: all 65536
  bytes zero, 0 non-zero bytes, `read()` semantics unchanged.
- fix.diff is `git apply`-clean against sys/kern/kern_subr.c.

## PoC changes vs the seed

No seed existed for this finding (discovered during pass 2 of
sys/kern/kern_subr.c). Harness authored fresh; needed two fixes during
bring-up: (1) out-of-tree KLD builds require `SYSDIR=/usr/src/sys` in
the Makefile; (2) DragonFly devfs requires an explicit `.d_open`
handler or open(2) fails ENODEV.