DF-0779 — tmpfs_readdir cookie-generation panic on attacker-supplied bogus NFS cookie

Verdict: REPRODUCED (panic / DoS) — and FIX VALIDATED on a single-fix kernel.

The bug (confirmed by source trace + live panic)

tmpfs_readdir() (sys/vfs/tmpfs/tmpfs_vnops.c) maintains a separate "NFS cookie-generation" block (tmpfs_vnops.c:1697-1731) that runs only when the caller passes a non-NULL cookies/ncookies vector (tmpfs_vnops.c:1697). The block re-walks the directory's cookie RB-tree starting at the caller-supplied startoff cookie (off = startoff, line 1699) and ends with the invariant

KKASSERT(uio->uio_offset == off);   /* tmpfs_vnops.c:1730 */

startoff is the readdir cookie. The only VOP_READDIR callers that pass non-NULL cookies are the NFS server (sys/vfs/nfs/nfs_serv.c:3045 and :3337). In nfsrv_readdir the cookie is taken raw and unvalidated from the NFS client's READDIR RPC payload:

toff = fxdr_hyper(tl);          /* nfs_serv.c:2963 - straight off the wire */
...
io.uio_offset = (off_t)off;     /* nfs_serv.c:3035 */
error = VOP_READDIR(vp, &io, cred, &eofflag, &ncookies, &cookies);  /* :3045 */

(the only guard that ever existed, a verf cookie-verifier check at nfs_serv.c:3009, is #if 0).

A bogus client cookie (one that does not exactly map to a live dirent) makes tmpfs_dir_getdents() silently snap uio_offset to TMPFS_DIRCOOKIE_EOF (tmpfs_subr.c:893) and return 0 entries (cnt == 0). The cookie-generation block, however, still has off == startoff (the bogus value), so the final invariant fires:

panic: assertion "uio->uio_offset == off" failed in tmpfs_readdir
       at /usr/src/sys/vfs/tmpfs/tmpfs_vnops.c:1730
tmpfs_readdir() at tmpfs_readdir+0x537
vop_readdir()   at vop_readdir+0x6b
nfsrv_readdir() at nfsrv_readdir+0x378      <- NFS server READDIR path
sys_nfssvc()    at sys_nfssvc+0x40f
syscall2()      at syscall2+0x11e

(For a different bogus value whose tmpfs_cookiedir() lands between two real dirents, tmpfs_dir_getdents reads entries from the predecessor and the cookie block's first iteration trips KKASSERT(de != NULL) at tmpfs_vnops.c:1719 instead. Both are the same root cause: an unvalidated cookie desyncs the cookie block. The cited range 1697-1731 covers both.)

tmpfs is fully NFS-exportable (vfs_fhtovp/vfs_vptofh/vfs_checkexp are all implemented, tmpfs_vfsops.c:549-551), so the path is live.

Reachability & threat model (honest)

• NOT reachable via local getdents. Local readdir goes through kern_getdents → VOP_READDIR_FP(vp, &auio, fp->f_cred, &eofflag, NULL, NULL, fp) (vfs_syscalls.c:4645) — cookies=NULL, so the panic block is skipped. Verified empirically: ./df0779_local on a tmpfs dir with cookies 0xDEAD, 0x7FFF…FF, 0x4141…41, 0x0BADF00D all returned gracefully (no panic, guest stayed up). The finding's "unprivileged local getdents" framing is therefore incorrect.
• Reachable via the NFS server. Any NFS client (local over 127.0.0.1 or remote over the network) that issues a READDIR against an NFS-exported tmpfs directory with an out-of-range cookie panics the server kernel. The trigger (df0779_trigger) needs a valid filehandle for the dir; in the realistic threat a legitimate client already holds one (from a prior permitted MOUNT), and the malicious packet is just a normal READDIR with a mutated cookie field.
• Impact: kernel panic → full-system DoS (the NFS-serving box goes down and must reboot). This is a deliberate INVARIANTS KKASSERT, not memory corruption — there is no write/UAF/control primitive, hence no escalation path (valid Phase-6 hard blocker: pure assertion panic). On an INVARIANTS-OFF build the KKASSERT is compiled out and the divergence is benign (empty reply), so the primitive is DoS-only on every kernel flavour.

Files

Reproduce

./build.sh
# PATH A (as unprivileged user) -- no panic:
./df0779_local /tmp/some_tmpfs_dir
# PATH B (as root, with NFS serving a tmpfs export):
#   see run.sh for the rpcbind/mountd/nfsd + /etc/exports setup, then:
./df0779_trigger /tmp/df0779_export 0xDEAD     # unpatched: panic; patched: clean reply

DF-0779 — VERDICT

REPRODUCED (panic / DoS) on the unpatched 6.5-DEVELOPMENT #0 kernel. FIX VALIDATED on a single-fix #1 kernel.

Mechanism (every hop cited)

1. An NFS client sends a READDIR RPC whose 64-bit cookie is attacker-chosen and bogus (does not map to any live tmpfs dirent).
2. nfsrv_readdir() decodes it raw and unvalidated: toff = fxdr_hyper(tl); (sys/vfs/nfs/nfs_serv.c:2963), then io.uio_offset = (off_t)off; (nfs_serv.c:3035), then VOP_READDIR(vp, &io, cred, &eofflag, &ncookies, &cookies); (nfs_serv.c:3045) — non-NULL cookies, so tmpfs's NFS cookie-generation block runs.
3. In tmpfs_readdir() the bogus startoff is captured (tmpfs_vnops.c:1662, off = startoff at :1699). tmpfs_dir_getdents() (tmpfs_vnops.c:1684) handles the bogus cookie gracefully: its inexact tmpfs_dir_lookupbycookie(node, startcookie, 0) (tmpfs_subr.c:891) returns NULL for a cookie below all dirent cookies, so it snaps uio_offset = TMPFS_DIRCOOKIE_EOF and returns 0 (tmpfs_subr.c:892-895).
4. Back in the cookie block, cnt == 0 so the cookie loop (for (i = 0; i < cnt; i++), tmpfs_vnops.c:1705) never executes; off is still the bogus startoff ≠ uio_offset == EOF.
5. The trailing KKASSERT(uio->uio_offset == off); (tmpfs_vnops.c:1730) fires → panic. (For a cookie whose tmpfs_cookiedir() lands between two real dirents, tmpfs_dir_getdents reads from the predecessor and the block's first iteration trips KKASSERT(de != NULL) at :1719 instead. Same root cause; both inside the cited 1697–1731 range.)

Captured panic (boot.log):

panic: assertion "uio->uio_offset == off" failed in tmpfs_readdir
       at /usr/src/sys/vfs/tmpfs/tmpfs_vnops.c:1730
tmpfs_readdir() at tmpfs_readdir+0x537
vop_readdir()   at vop_readdir+0x6b
nfsrv_readdir() at nfsrv_readdir+0x378
sys_nfssvc()    at sys_nfssvc+0x40f

Reachability — the local-getdents framing is wrong

Exhaustive VOP_READDIR call-site survey in sys/:

So local getdents cannot trigger it (cookies == NULL). Verified live: ./df0779_local on a tmpfs dir with cookies 0xDEAD / 0x7FFF…FF / 0x4141…41 / 0x0BADF00D / 0x2 all returned rc=0 with no panic, guest stayed up.

The real trigger is an NFS READDIR against an NFS-exported tmpfs dir. tmpfs is fully exportable (vfs_fhtovp/vfs_vptofh/vfs_checkexp, tmpfs_vfsops.c:549-551). Any NFS client (localhost or network) holding a valid filehandle (from a permitted MOUNT) can send the malformed READDIR.

Impact

Kernel panic → full-system DoS of the NFS-serving host (reboot required). This is a deliberate INVARIANTS KKASSERT, not memory corruption: no write/UAF/control primitive exists, so there is no escalation path (valid Phase-6 hard blocker: pure assertion panic). Severity Medium is appropriate (remote DoS of a non-default-but-supported service).

PoC changes from the seeded draft

The seeded draft (a local getdents PoC) was incorrect: local getdents passes cookies=NULL and never reaches the panic block. I replaced it with: - df0779_local.c — kept as the negative control proving the local path is safe (no panic for any bogus cookie). - df0779_trigger.c — the real trigger: a hand-rolled NFSv3 READDIR over UDP to the local nfsd, using getfh(2) to obtain the directory filehandle (mountd rejected AUTH_NONE/AUTH_UNIX as AUTH_TOOWEAK on this guest, so the MOUNT RPC path was unusable; getfh yields the identical fh). The cookieverf3 field is encoded as NFSv3 fixed opaque[8] (no length prefix), which was the one encoding subtlety. - df0779_nfs.c, diag.c, diag2.c — investigation artefacts (mountd/auth probing) retained for the record.

Fix

fix.diff validates the readdir cookie at the top of tmpfs_readdir: if startoff is not one of the reserved DOT/DOTDOT/EOF markers and does not exactly match a live dirent (tmpfs_dir_lookupbycookie(node, startoff, 1) == NULL), it is snapped to TMPFS_DIRCOOKIE_EOF (and uio_offset too), exactly matching the EOF semantics tmpfs_dir_getdents() already applies. One logical change; applies clean (git apply --check OK); builds (make nativekernel, NK_DONE rc=0).

Validation (Phase 8)

fix_kernel_uname: DragonFly 6.5-DEVELOPMENT #1: Fri Jul 10 03:58:53 UTC 2026 (kernel.stripped sha256 184c1fc2063c6eb5b181695044d4134b3969f06ccc913ee2e2905d1300b75a2d). Cookie 0x4141414141414141 (overshoot) also returns a clean 132-byte reply on the patched kernel. fix_status = fixed.