DF-5831 — nlookup() retry path NULL-derefs nd->nl_basench for nlookup_init_raw() nd's → remote NFS-server kernel panic

What

nlookup()'s internal retry path (added for autofs mounts / NFS ESTALE / namecache generation changes) resets the lookup to the base directory:

    sys/kern/vfs_nlookup.c:1367-1385
    if (doretry && !inretry) {
        ...
        cache_drop(&nd->nl_nch);
        cache_copy(nd->nl_basench, &nd->nl_nch);   /* :1380 */
        ...
        goto nlookup_start;
    }

nl_basench is only ever initialized by nlookup_init() (vfs_nlookup.c:149/159/170) and nlookup_init_at() (:225/228/239). nlookup_init_raw() (:255-291) and nlookup_init_root() (:297-335) leave it NULL (the whole nd is bzero()'d).

Any doretry during an nlookup on an init_raw/_root-initialized nd therefore executes cache_copy(NULL, &nd->nl_nch):

    sys/kern/vfs_cache.c:996-1000
    void cache_copy(struct nchandle *nch, struct nchandle *target)
    {
        ...
        ncp = nch->ncp;     /* NULL deref, ncp is at offset 0 */

→ Fatal trap 12: page fault on read at 0x0 in cache_copy+0x11.

Reachability

nlookup_init_raw() is called from:

• nfs_namei() (sys/vfs/nfs/nfs_subs.c:1155) — the NFS server's name resolution for every RPC carrying a (dir filehandle, name) pair: LOOKUP, CREATE, REMOVE, RENAME (both sides), MKDIR, LINK, SYMLINK, SETATTR/GETATTR-by-name, etc.
• nfsrv3_public (sys/vfs/nfs/nfs_serv.c:568) — the WebNFS public filehandle index lookup.
• vfs_mountroot_devfs() (sys/kern/vfs_conf.c:238) — boot only.

nlookup_init_root() — vfs_synth only (boot).

The doretry triggers, all raceable by an NFS client against concurrent modification of the exported tree (a second client, a second thread of the same client, or a local process):

• generation change of the start directory or any component, detected at vfs_nlookup.c:1148-1158 / :1313-1323 — e.g. a concurrent RENAME sub -> sub2 of the directory being searched bumps its nc_generation (_cache_unlink_parent + _cache_link_parent both _cache_ncp_gen_enter/exit, vfs_cache.c:783/840, 2155);
• parent destroyed (NCF_DESTROYED) during the leaf lookup, vfs_nlookup.c:1229-1232 — rename-over of the directory;
• ESTALE from cache_resolve (vfs_nlookup.c:802-806, :882-886);
• the trailing-./.. EINVAL retry (vfs_nlookup.c:848-852).

Impact: kernel panic in the nfsd process — remote denial of service of the NFS server by any client permitted by the exports (no authentication beyond the export ACL); also reachable by ordinary concurrent NFS workloads (lookups racing renames of the containing directory) without hostile intent. Not enabled by default (requires the NFS server to be running), hence High rather than Critical.

Files

• hammer.c — client-side LOOKUP hammer: stat("/mnt/nfs/sub/zzzNNN") loop → server-side nfsrv_lookup → nfs_namei → nlookup with nl_basench == NULL.
• renamer.c — renames sub <-> sub2 (locally on the export and over the NFS mount) to churn sub's nc_generation.
• run.sh — sets up the loopback NFS server + client, runs the rig.
• panic.txt — captured panic (see below).
• fix.diff — verified fix.
• build.log, run.log, run.2.log — fix-validation kernel build and the two post-fix survival runs.

Reproduce

In the guest (as root):

sh /root/poc/DF-5831/run.sh

Expected on a vulnerable kernel (observed ≤ 2 minutes into the run):

kern_rename: retry due to race on: "sub" -> "sub2" (16,0)
Fatal user address access from kernel mode from nfsd at ffffffff806dac71
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
...
Stopped at      cache_copy+0x11:        movq    (%rdi),%r13

current process is the nfsd; the fault is a read of NULL->ncp (ncp is the first member of struct nchandle), i.e. exactly cache_copy(nd->nl_basench, ...) with nd->nl_basench == NULL.

DF-5831 VERDICT — REPRODUCED (kernel panic, remotely triggerable via NFS)

Bottom line

Reproduced on the first guest run, in under two minutes of racing. The stock INVARIANTS guest (DragonFly 6.5-DEVELOPMENT, see env.txt) panicked in the nfsd process with exactly the predicted signature:

kern_rename: retry due to race on: "sub" -> "sub2" (16,0)
Fatal user address access from kernel mode from nfsd at ffffffff806dac71
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
...
Stopped at      cache_copy+0x11:        movq    (%rdi),%r13

(panic.txt — captured from the serial console; the run started at 10:43 UTC, the ssh session died and the guest was down by 10:46 UTC.)

Why this is the bug I claimed (not some other crash)

1. Stopped at cache_copy+0x11: movq (%rdi),%r13 — cache_copy's first instruction sequence loads nch->ncp (ncp is the first member of struct nchandle, sys/sys/namecache.h); the fault is a read at virtual address 0x0 with %rdi == NULL, i.e. the first argument of cache_copy() was NULL.
2. cache_copy(nd->nl_basench, ...) is called with a NULL first argument from exactly one site reachable in the nfsd process: sys/kern/vfs_nlookup.c:1380 (nlookup's doretry reset block). The other four call sites (vfs_nlookup.c:150, 160, 171, 242) pass &fd_ncdir / &fd_nrdir / &fp->f_nchandle — never NULL.
3. nfs_namei() (sys/vfs/nfs/nfs_subs.c:1155) initializes its nd with nlookup_init_raw(), which bzero()s the whole structure and never sets nl_basench (vfs_nlookup.c:265 vs. :280-290). Every server-side name RPC (LOOKUP/CREATE/REMOVE/RENAME/...) goes through it.
4. The doretry fired on a namecache generation change: the console shows kern_rename: retry due to race on: "sub" -> "sub2" immediately before the trap — my racer was renaming the looked-up directory sub <-> sub2, and _cache_unlink_parent() + _cache_link_parent() both _cache_ncp_gen_enter/exit() the renamed ncp (sys/kern/ vfs_cache.c:783/840, 2155), which nlookup() detects at vfs_nlookup.c:1313-1332 and turns into doretry = TRUE.
5. Current process = nfsd (pid 1025) — the NFS server thread, i.e. the crash was driven by client RPCs racing a concurrent rename, not by the local racer's own path (a local rename uses nlookup_init() and has a valid nl_basench).

Exploit chain / impact

Remote denial of service (kernel panic) of an NFS server by any client permitted by the exports: hammer LOOKUP RPCs on names inside a directory while the same (or another) client renames that directory. No authentication beyond the export ACL. Also reachable as a reliability crash by ordinary concurrent NFS workloads. The fault is a deterministic NULL deref — no memory-corruption primitive, no uid0 route (the guest is an intentionally permissive target, but NULL page mapping is not attacker-controllable here; this is panic-class only).

Fix validation

fix.diff (git-apply-able against the audit tree; applied with patch -p1 inside the guest's /usr/src):

• nlookup_init_raw() / nlookup_init_root() now store a private, ref-held copy of the start handle in a new nl_basench_store field of struct nlookupdata and point nl_basench at it;
• nlookup_done() drops the store.

Baseline (stock kernel): panic in nfsd ≤ 2 minutes into the rig (panic.txt). Patched (kernel rebuilt with make nativekernel KERNCONF=X86_64_GENERIC, rebooted): the identical rig ran to completion twice — full 300 s race window each, racers verified running, mount | grep nfs verified, no panic, guest stayed up, script printed NO PANIC (run.log, run.2.log). The previously-observed bad behavior is gone.

Kernel references

• sys/kern/vfs_nlookup.c:1367-1385 — retry block, cache_copy(nd->nl_basench, ...) at :1380
• sys/kern/vfs_nlookup.c:255-291 — nlookup_init_raw() never sets nl_basench
• sys/kern/vfs_nlookup.c:297-335 — nlookup_init_root() same
• sys/kern/vfs_cache.c:996-1000 — cache_copy() derefs nch->ncp (offset 0)
• sys/vfs/nfs/nfs_subs.c:1155 — nfs_namei() uses nlookup_init_raw()
• sys/kern/vfs_cache.c:783/840, 2155 — rename bumps nc_generation (_cache_ncp_gen_enter/exit)
• sys/kern/vfs_nlookup.c:1313-1332 — generation-change → doretry

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.