DF-2717 — VERDICT

Finding: nlookup_init()/retry path read the shared fd_ncdir/fd_nrdir nchandle pairs without fd_spin while sibling threads swap them — torn (ncp,mount) pairs and hold-after-drop race. sys/kern/vfs_nlookup.c:149-161. Filed Medium, "static protocol violation; not live-verified".

Verdict: The locking-protocol violation is confirmed by inspection, line-accurate — every reader and writer site was mapped and the two non-atomic loads plus the delayed _cache_hold in cache_copy were verified in source. The two race primitives claimed by the finding (torn two-word pair; _cache_hold after last-ref kfree_obj) did not land live within a quantified dedicated budget on the 6-vCPU INVARIANTS guest. However, the prescribed storm (chdir/fchdir swap + relative ".." lookups + mkdir/rmdir churn) panicked the guest 3/3 times in ≤90 s each — crash-dump analysis attributes the panic to a distinct adjacent bug in the same ".." machinery (unguarded NULL nc_parent at vfs_nlookup.c:756 dereferenced at :767), for which the DF-2717 unlocked reads are the delivery vehicle but not a necessary condition. Honest bottom line for DF-2717 itself: protocol violation real and certain at the source level; exploit window measured narrow (10^8-scale opportunities without a hit); no privilege escalation demonstrated. Recommend: keep as Medium hardening with the budget documented; file the NULL-parent panic separately (unpriv reliable local DoS — see below).

1. Protocol analysis (all path:line verified)

• Readers with NO lock: nlookup_init sys/kern/vfs_nlookup.c:149-166 (both / and relative branches read fd_nrdir/fd_ncdir/fd_njdir via cache_copy); nlookup_init_at :225-228,242; nlookup() generation-retry :1376-1378 re-dereferences nl_basench (a pointer into fdp->fd_ncdir/fd_nrdir) after an arbitrarily long walk.
• Writers: kern_chdir vfs_syscalls.c:1906-1911 and kern_fchdir :1900-1915 hold fd_spin around the two-word store and drop the old nchandle after unlock; mount-reload callback :572-593 holds fd_spin; fdcopy/fdshare kern_descrip.c:2411-2431/2528-2543 hold fd_spin. kern_chroot vfs_syscalls.c:2059-2066 updates fd_nrdir/fd_njdir under p_token only — no fd_spin, so even writer-vs-writer protocol is asymmetric.
• cache_copy sys/kern/vfs_cache.c:996-1026: ncp = nch->ncp (:1006) and mp = nch->mount (:1007) are two adjacent non-atomic loads; the reference is taken only later (_cache_hold(ncp) :1023, guarded by KKASSERT(ncp->nc_refs > 0) at :735) or stolen from the per-CPU mntcache. _cache_drop at 1→0 sets nc_refs = -1 (:763) and calls kfree_obj immediately (:766).

Consequences as filed are therefore source-certain: (a) a chdir/fchdir store can interleave between :1006 and :1007 producing a mismatched (ncp,mount) handle that flows into the mount-boundary and jail .. gates (vfs_nlookup.c:716-718, 745-746); (b) the gap between the load at :1006 and the hold at :1023 admits hold-after-free.

2. Live race budget (unprivileged user, stock INVARIANTS kernel)

The DF-2717 windows are real but narrow: 1.6×10^8 swap-vs-copy opportunities (torn pair) and 1.2×10^8 copy-vs-drop opportunities (hold-after-drop) produced zero hits. On this x86-64 guest the two-adjacent-loads/store interleaving effectively requires same-cycle co-residency that the scheduler rarely yields; likewise the freed chunk is typically re-used before the delayed hold. No KKASSERT in _cache_hold, no refcount corruption, no escalation. DF-2717 alone: not reproduced (impact of its own primitive: none within budget).

3. The panic that DID reproduce — adjacent bug, root-caused

Signature (3/3, identical): panic: page fault, nlookup() at nlookup+0x66c (sys/kern/vfs_nlookup.c:767) from kern_chdir(), fault VA 0x84, %rax = 0.

kgdb on /var/crash/vmcore.0 (logs in pack): nch = {ncp = 0x0}, nctmp = {ncp = 0x0}, nd->nl_nch.ncp = node with nc_parent = 0, nc_head = 0, nc_name = 0, nc_flag = 0x1210, nc_refs = 30, path "../../../tmp/df2717/a", element "..", last_element = 0; nl_basench's value sat on the hammer2 mount while the walk base sat on tmpfs (walk re-based mid-syscall through the init copy / retry re-deref).

Mechanism (each step source-verified):

1. rmdir(v) while v is the process cwd defers the zap (NCF_DEFEREDZAP) because nc_refs != refcmp — the fd-table ref is held. Single-threaded rmdir(cwd); ls .. works fine (verified on the guest) because the topology stays connected.
2. Under full-storm churn the deferred zap completes while fd_ncdir still holds the last reference: the node is unlinked (nc_parent = NULL, unhashed, unnamed) yet stays alive, referenced almost solely through fd_ncdir.
3. Reader/walker threads adopt the disconnected node as walk base via the DF-2717 sites (cache_copy(&fdp->fd_ncdir) at vfs_nlookup.c:159-160, retry re-deref at :1376-1378) — 30 references had accumulated by panic time.
4. The ".." handler runs nctmp.ncp = nctmp.ncp->nc_parent (vfs_nlookup.c:756) with no NULL check, the NULL flows through cache_copy (NULL-safe) into nch, and nch.ncp->nc_generation at :767 faults (NULL+0x84). The intended NULL-parent handling ((par.ncp = nch.ncp->nc_parent) != NULL at :831) exists but runs after the unguarded deref.

Attribution to DF-2717: step 3 uses the finding's unlocked read sites as the delivery vehicle, but a correctly locked reader would copy the same disconnected handle (the value in fd_ncdir is legitimate between the deferred-zap completion and the chdir-away). The panic therefore does not depend on the missing lock; its root causes are the deferedzap-vs-cwd disconnect and the missing NULL guard. It should be filed as its own finding: unprivileged, reliable local DoS (panic) with a trivial trigger program (this pack's df2717_storm 90 3 0xf).

4. Fix and A/B validation

fix.diff has two parts:

• Part A (DF-2717): fd_spin around the fd_nchandle reads in nlookup_init (both branches incl. fd_njdir), guarded fd_spin in nlookup_init_at and in the nlookup() retry when nl_basench points into the caller's fdp; kern_chroot now takes fd_spin around its fd_nrdir/fd_njdir updates with vrele/cache_drop deferred outside the spinlock (matches kern_chdir's pattern). cache_copy is spinlock-safe (atomics only; the source comment at vfs_cache.c:725-732 explicitly blesses spinlock-holding callers).
• Part B (the reproduced panic): after nctmp.ncp = nctmp.ncp->nc_parent, recover with nctmp = nd->nl_rootnch — the same recovery the function already uses for the jail-break NULL case — instead of dereferencing NULL. (Semantics note: ".." from a topology-disconnected cwd then resolves relative to the process root; jailed processes get their jail root, so no escape is introduced.)

Validation performed on the guest (patched kernel #1: Tue Oct 20 08:31:33 UTC 2026 built from the guest's /usr/src with exactly the diff below — verified byte-identical to the validated sources; full kernel build log: buildkernel-fixed.log, RC=0):

• Full-mix storm re-run twice, 150 s each: no panic, guest up (run-fixed-storm.log; run 1: 114,908,038 swaps + 3,144,309 dance cycles + 138,997,980 opens; run 2: 162,930,640 swaps + 2,326,609 dance cycles + 131,940,060 opens). Baseline: 3/3 panics in ≤90 s. No "..' traverse disconnected" guard messages fired in these two runs (the underlying disconnect chain is probabilistic; the guard is defense-in-depth for the crash case).
• Microbench (2,000,000 relative-path open() best-of-3): stock 458,786 ops/s (2.18 µs/op) vs patched 450,273 ops/s (2.22 µs/op) — ≈1.9 % delta, within the guest's run-to-run noise band (stock itself varied 454,552–458,786 across its two runs).

5. Notes

• Jail variant not run: fd_njdir has no concurrent writer once a jail exists (only kern_chroot before jail setup writes it), so the torn-read surface for the jail nch copy is nil; the ".." gate itself (vfs_nlookup.c:745-749) was exercised by every storm run via the tmpfs/hammer2 mount crossings.
• The debug.nlookup_debug sysctl bits are kprintf verbosity only (vfs_nlookup.c:969,1043,1153,1177,1256,1314,1368) — they cannot force the retry path; retries occurred naturally from the dance's generation churn.
• Guest was returned to a clean state (vm.sh reset with-src) after validation.

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.