DF-2996 — nfs_sillyrename consumes nfs_lookitup() result without any validation → wild-pointer write / VDIR type confusion → deterministic kernel panic (malicious NFS server; unpriv local trigger)

What this is

The NFS client's silly-rename machinery (unlink() of an open file) calls nfs_lookitup() for the freshly renamed .nfsXXX entry and then executes

    error = nfs_lookitup(dvp, sp->s_name, sp->s_namlen, sp->s_cred,
        cnp->cn_td, &np);
    np->n_sillyrename = sp;          /* sys/vfs/nfs/nfs_vnops.c:3036-3038 */
    return (0);

with no error check, no initialization of np, and no verification that the node returned is the renamed file. nfs_lookitup() leaves *npp untouched on error, and returns whatever nfsnode the server's file handle maps to. Consequences:

1. error path: np is uninitialized caller stack → np->n_sillyrename = sp is a wild-pointer write of a heap pointer (sp).
2. non-NULL garbage np: nfs_lookitup() takes its *npp != NULL branch → overwrites the file handle of an arbitrary node (bcopy(nfhp, np->n_fhp, fhlen)) and applies the server's attributes to it — including a type change (nfs_setvtype()), observed turning a VREG node into VDIR.
3. server returns a directory's fh: np->n_sillyrename aliases the n_cookies LIST_HEAD on VDIR nodes (union in struct nfsnode, sys/vfs/nfs/nfsnode.h:131-132) → nfs_reclaim() walks and kfree()s sp (a struct sillyrename from M_NFSREQ) as an nfsdmap (M_NFSDIROFF) → wild pointer walk + wrong-zone frees.

Trigger: any unprivileged local user unlink()ing a file that is still open, against a mounted NFS share whose server (malicious, compromised, or spoofing on-path — AUTH_SYS/UDP has no integrity) replies to the final LOOKUP with an error or a lying file handle.

Build (in-guest, base system cc)

cd /root/df2996
cc -O -o fakesrv fakesrv.c
cc -O -o trigger trigger.c
cc -O -o lsdir   lsdir.c

Run (baseline — stock INVARIANTS kernel)

cd /root/df2996
(./fakesrv dirfh > /tmp/fakesrv.log 2>&1 &)   # fake rpcbind+mountd+nfsd on 127.0.0.1
sleep 1
mount_nfs -o port=2049,udp 127.0.0.1:/P /mnt
mkdir /mnt/d
./trigger                                      # open + unlink-while-open

Expected (baseline)

• trigger prints fd=N open..., unlink returned 0, and then the kernel panics before/during trigger exit:

Fatal user address access from kernel mode from trigger at ffffffff807f61b0
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x1
instruction pointer = 0x8:0xffffffff807f61b0
Stopped at      nfs_reclaim+0x150:      movq    (%rdi),%r12

nfs_reclaim+0x150 is exactly the directory-cookie free loop (dp = dp->ndm_list.le_next / kfree(dp, M_NFSDIROFF), sys/vfs/nfs/nfs_node.c:466-473) — 3/3 deterministic reproductions.

• Alternate mode ./fakesrv err: final LOOKUP replies NFSERR_NOENT. The wild write happens silently (unlink still returns 0); on this guest the uninitialized stack slot held a benign value, so no fault — evidence that the error path corrupts whatever the stale pointer points at.

Expected (after fix.diff, rebuilt kernel)

• ./trigger under fakesrv dirfh or fakesrv err: unlink fails with an RPC error (EBADRPC/EIO-ish), no panic, guest stays up, /mnt remains usable. Verified in run.fixed.log.

Files

• fakesrv.c — malicious NFSv3 server (rpcbind :111, mountd :779, nfs :2049)
• trigger.c — open + unlink-while-open + post-unlink stat probe
• lsdir.c — bounded getdents reader (leak-demo helper)
• run.baseline.log / panic.txt — baseline reproduction
• run.fixed.log — same PoC on the fixed kernel
• fix.diff — the verified fix (nfs_sillyrename validation + nfs_lookitup echo branch)

DF-2996 VERDICT — nfs_sillyrename stores sp through an unvalidated nfsnode → wild write / VDIR cookie-list type confusion → deterministic kernel panic

Status: REPRODUCED — impact: panic (kernel memory corruption, deterministic) Fix v2 validated on a rebuilt kernel: all malicious modes cleanly rejected, honest mode fully functional, zero panics.

Root cause (line-accurate)

sys/vfs/nfs/nfs_vnops.c:3036-3038 (nfs_sillyrename, reached by any unlink() of an open file — unpriv user, any NFS mount):

    error = nfs_lookitup(dvp, sp->s_name, sp->s_namlen, sp->s_cred,
        cnp->cn_td, &np);
    np->n_sillyrename = sp;
    return (0);

Three independent defects in two lines:

1. np is uninitialized (struct nfsnode *np; at :2993) and the error return is ignored — on ANY lookup failure np->n_sillyrename = sp is a wild-pointer write through stale stack contents, and the error is swallowed (unlink() returns 0).
2. On success with garbage non-NULL np, nfs_lookitup() takes its *npp != NULL update branch (:3077-3086): it overwrites the file handle of whatever node the stale pointer selects (bcopy at :3084) and applies the server's attributes to that node — including type changes (nfs_setvtype, sys/vfs/nfs/nfs_subs.c:718-731). Demonstrated: even an HONEST final LOOKUP reply crashes the stock kernel this way ("control" mode).
3. On success with any server-chosen node, identity and type are never validated: n_sillyrename (n_un3.nf_silly) aliases the directory cookie LIST_HEAD n_un3.nd_cook (sys/vfs/nfs/nfsnode.h:125-133). Storing sp on a VDIR node (server returns a directory fh, OR the object attrs retype the node VREG→VDIR — "typelie" mode, which needs no fh lie at all) plants sp as n_cookies.lh_first.

The crash sink — nfs_reclaim() cookie walk (sys/vfs/nfs/nfs_node.c:466-473):

    if (vp->v_type == VDIR) {
        dp = np->n_cookies.lh_first;        /* = sp          */
        while (dp) {
            dp2 = dp;
            dp = dp->ndm_list.le_next;  /* *(sp+8)=s_dvp */
            kfree((caddr_t)dp2, M_NFSDIROFF); /* wrong zone  */
        }
    }

Reproduction matrix (guest = DragonFly 6.5-DEVELOPMENT, INVARIANTS

X86_64_GENERIC; fake userland NFSv3 server in-guest; DF wire order for LOOKUP replies as emitted by DragonFly's own nfsrv_lookup [ fh ][ object attrs ][ dir attrs ] — sys/vfs/nfs/nfs_serv.c:652-656)

Panic signature (identical every time; captured via serial console + DDB trace through a socket serial):

Fatal user address access from kernel mode from trigger at ffffffff807f6[1b0|6aa0]
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1
Stopped at nfs_reclaim+0x150: movq (%rdi),%r12

trace:
nfs_reclaim() at nfs_reclaim+0x150
vop_reclaim() at vop_reclaim+0x4b
vgone_vxlocked() at vgone_vxlocked+0x266
vrecycle() at vrecycle+0x48
nfs_inactive() at nfs_inactive+0xfe      <- close(fd) of the unlinked file
vop_inactive() ... vrele() ... vn_close() ... kern_close() syscall2()

Disassembly of the faulting instruction region (both stock snapshots and the rebuilt kernels) confirms +0x150 is the cookie walk:

+0x134: mov 0x198(%rbx),%rdi   ; dp = np->n_cookies.lh_first
+0x150: mov (%rdi),%r12        ; dp = dp->ndm_list.le_next   <<< FAULT (dp=1)
+0x15b: call _kfree            ; kfree(dp2, M_NFSDIROFF)
+0x160: jne +0x150             ; while (dp)

The typelie run is the cleanest demonstration that the bug is fully client-side reachable with a well-formed reply: the file's own file handle + directory-typed attributes. nfs_lookitup() applies the attrs (vnode retyped VREG→VDIR mid-life), the identity check passes, sp is stored into the cookie head, and the very next close() of the unlinked file reclaims the node and walks sp → s_dvp (a struct vnode * reinterpreted as nfsdmap *) → wild walk → kfree(sp, M_NFSDIROFF) (wrong zone) → page fault at 0x1.

Additional primitives in the same line (not pushed to uid=0 within this run): mode err is an 8-byte heap-pointer write at a stale-stack-chosen address; the cookie-slot window sp+20+4*pos (pos ≥ 5) reads/writes past the 40-byte sp into adjacent M_NFSREQ objcache objects with server-chosen 64-bit cookie values, and those bytes are echoed back to the server in subsequent READDIR cookies (kernel-heap disclosure).

Fix validation

fix.diff (v2; applied only inside the guest's /usr/src, kernel rebuilt with make nativekernel KERNCONF=X86_64_GENERIC):

1. nfs_sillyrename: initialize np = NULL; check the error; require the returned node to be the renamed file (fh identity) and still VREG (type) — otherwise release the acquired vnode (vput / vrele for the parent-echo case), free sp, and fail with EBADRPC.
2. nfs_lookitup: the parent-fh-echo branch sets np = dnp so *npp can never remain uninitialized on success (DF-0767's root cause).

Baseline: stock panics (dirfh 4/4, control 1/1, typelie/freshdir observed). Patched: all five modes clean (run.fixed.log), honest lifecycle unaffected.

Honesty notes

• The earliest baseline runs used a fake-server LOOKUP reply in RFC order ([dir attrs][fh][obj attrs]) while the DragonFly client parses [fh][obj attrs] — those runs still panicked identically (the misaligned attrs fed the same type-confusion machinery), but the final matrix above was re-run with the server matching DragonFly's actual wire order, so the reported mechanisms correspond exactly to well-formed (or precisely-lying) server replies.
• An OOM side-effect observed in one matrix iteration (client ls reading an endless fake directory) was a fake-server artifact, removed by giving the fake directory a finite size; it is unrelated to the finding.