DF-2816 — boot()/shutdown_cleanup_proc() tears down the calling process while its sibling threads still run

What

sys_reboot() → boot() (sys/kern/kern_shutdown.c:250) calls shutdown_cleanup_proc(curproc) at kern_shutdown.c:291 while the calling process's other threads keep running on the other CPUs — nothing stops them (only initproc gets a SIGSTOP + wait at :293-297; other CPUs are never stopped in the sys_reboot path).

shutdown_cleanup_proc() (kern_shutdown.c:566-610) then, on the live process:

• kern_closefrom(0) closes every fd (:576),
• cache_drop(&fdp->fd_ncdir) — which NULLs fd_ncdir.ncp and .mount (sys/kern/vfs_cache.c:1090-1096) — and likewise fd_nrdir / fd_njdir (:577-591),
• pmap_remove_pages() + vm_map_remove(VM_MIN_USER_ADDRESS, VM_MAX_USER_ADDRESS) — destroys the whole user address space (:601-609).

A sibling thread that subsequently enters the kernel on any other CPU:

• doing a path lookup: nlookup_init() copies fd_ncdir/fd_nrdir into nd->nl_nch with no NULL-ncp guard (sys/kern/vfs_nlookup.c:149-161; cf. the guarded fd_njdir at :153/163), and nlookup()'s permission check naccess() dereferences nch->ncp at +0x58 (vfs_nlookup.c:655-659) → NULL-deref page fault → kernel panic;
• doing any syscall with copyin/copyout of its now-unmapped user memory → fatal "user address access from kernel mode" → panic.

Reproduced

Two independent triggers on DragonFly 6.5-DEVELOPMENT x86_64 (X86_64_GENERIC, INVARIANTS), 2/2 + 1/1 deterministic:

1. race2 (4 sibling threads spamming ioctl(DIOCGKERNELDUMP) + main thread calling reboot(RB_DUMP)) — panic in naccess+0x33 ← nlookup+0x15e, fault virtual address = 0x58, process race2, faulting CPU = a churn CPU (serial.naccess-panic.log / panic trace in VERDICT). Reproduced twice.
2. sibs (4 sibling threads doing only open("etc/passwd") in a loop + main thread calling reboot(RB_DUMP|RB_NOSYNC)) — identical naccess+0x33 NULL-deref panic, then an IPI-wedged machine (send_ipiq N->M tgt not draining) — a hard hang, not even a clean panic reboot.

Decisive serial output (from race2):

Fatal user address access from kernel mode from race2 at ffffffff806ee803
Fatal trap 12: page fault while in kernel mode
fault virtual address    = 0x58
instruction pointer      = 0x8:0xffffffff806ee803
current process          = 879 (race2)
panic: page fault
naccess() at naccess+0x33
nlookup() at nlookup+0x15e

with naccess+0x33 disassembled (stock kernel) as:

ffffffff806ee7ee: 4c 8b 3e        mov    (%rsi),%r15      ; r15 = nch->ncp
ffffffff806ee803: 41 0f b7 57 58  movzwl 0x58(%r15),%edx  ; NULL+0x58 -> trap

Impact

Kernel NULL-deref panic / hard wedge during reboot(2). Requires the reboot privilege (SYSCAP_NOREBOOT, kern_shutdown.c:186) in the calling process — i.e. an already-privileged user converts a clean reboot into a kernel panic with a wedge (and a corrupted/absent crash dump). Not an escalation; robustness/reliability defect with a trivially reliable trigger. Defense-in-depth note: any future caller of boot() outside sys_reboot inherits the same hazard.

Fix

fix.diff (verified in-guest): only run shutdown_cleanup_proc(curproc) when the process is single-threaded (curproc->p_nthreads < 2); multi- threaded callers keep their state through the shutdown (harmless — forced unmount already copes with lingering refs). Recommended hardening on top: NULL-guard the cache_copy(&fdp->fd_ncdir/fd_nrdir, ...) anchors in nlookup_init() (vfs_nlookup.c:149-161), mirroring the existing fd_njdir.ncp checks.

DF-2816 VERDICT — REPRODUCED (kernel NULL-deref panic: boot() teardown vs sibling threads)

Bottom line

boot() calls shutdown_cleanup_proc(curproc) (kern_shutdown.c:291) on the live reboot(2)-calling process while its sibling threads keep running on other CPUs. The cleanup closes every fd, cache_drop()s (and thereby NULLs, vfs_cache.c:1090-1096) fd_ncdir/fd_nrdir/fd_njdir, and vm_map_remove()s the entire user address space (kern_shutdown.c:601-609). A sibling thread that then performs a path lookup copies the NULL-ed nchandle into nd->nl_nch — nlookup_init() has no NULL-ncp guard for the cwd/root anchors (vfs_nlookup.c:149-161, unlike fd_njdir at :153/163 — and nlookup_init is also racy against fd_cdir NULLing) — and naccess() dereferences the NULL ncp at +0x58 (vfs_nlookup.c:655-659, disassembly naccess+0x33 movzwl 0x58(%r15),%edx with r15==NULL).

Reproduction

Stock INVARIANTS kernel (DragonFly 6.5-DEVELOPMENT #0 Jul 2 2026, X86_64_GENERIC), debugger_on_panic=0 trace_on_panic=1 for serial traces.

1. race2 (MARK-3, MARK-4): 4 sibling threads spam ioctl(DIOCGKERNELDUMP) + heartbeat writes; main thread calls reboot(RB_DUMP). Panic on a churn CPU in naccess+0x33 ← nlookup+0x15e, fault VA 0x58, process race2. 2/2 runs. (serial.race2-panic.log / serial.race2-full.log)
2. sibs (SIBS-MARK-1): minimal deterministic trigger — 4 siblings looping only open("etc/passwd") (relative path → fd_ncdir anchor); main calls reboot(RB_DUMP|RB_NOSYNC). Identical naccess+0x33 panic on cpu3, then the machine wedges hard: send_ipiq 2->4 tgt not draining forever, no DDB, no reboot — a hang, not even a panic reboot (the panic crossfire left cpu4 non-draining). 1/1 run. (serial.sibs-panic.log)

Which sibling syscall triggers it is workload-dependent (any relative or absolute path lookup — the root anchor fd_nrdir is equally unguarded at vfs_nlookup.c:149-152); copies from user memory after the vm_map_remove fault fatally in kernel mode the same way ("Fatal user address access from kernel mode").

Impact / escalation ceiling

Kernel NULL-deref panic and, in the observed sibs run, a hard machine wedge during shutdown, with the crash dump corrupted/lost. Requires the reboot privilege (SYSCAP_NOREBOOT, kern_shutdown.c:186) — an already- privileged user turning a clean reboot into a kernel panic/wedge. No memory-control primitive beyond the NULL deref (the torn state is a NULLed handle, not attacker-controlled data); x86-64 userland cannot map page 0 (VM_MIN_USER_ADDRESS), so no NULL-page pivot. Not an escalation; reliability/robustness defect with a trivial, deterministic trigger.

Fix validation

fix.diff: only run shutdown_cleanup_proc(curproc) when the process is single-threaded (curproc->p_nthreads < 2); multi-threaded callers keep their state through shutdown (harmless — forced unmount handles lingering refs; the machine resets immediately after). Built and validated in the same patched-kernel run as DF-2815: sibs 4 now reboots cleanly with no panic and no wedge (run.patched.log). Recommended hardening on top: guard cache_copy(&fdp->fd_ncdir/fd_nrdir, ...) in nlookup_init (vfs_nlookup.c:149-161) for fd_njdir-parity.

Kernel references

• sys/kern/kern_shutdown.c:290-301 (unguarded curproc cleanup; contrast initproc SIGSTOP at :293-297), :566-610 (shutdown_cleanup_proc: closefrom, cache_drop of fd_ncdir/fd_nrdir/fd_njdir, pmap/vm_map teardown)
• sys/kern/vfs_cache.c:1090-1096 (cache_drop NULLs the nchandle)
• sys/kern/vfs_nlookup.c:145-177 (un NULL-guarded cwd/root anchors), :655-659 + disasm (naccess NULL ncp deref sink)