DF-5660 — VERDICT

Status: reproduced (impact: dos — host-wide reboot/poweroff attempt; the primitive is the host reboot(2) request itself, executed from kernel context; no kernel-side check exists downstream).

What was proven, and how

1. The symbol binding (certain)

• No kernel object defines reboot: the syscall entry is sys_reboot (kern_shutdown.c:182) and the shutdown engine is static void boot(int) (kern_shutdown.c:158). grep -rn "[^_]reboot(" sys/ finds exactly one bare caller: shutdown.c:97.
• The vkernel links as a host program: SYSTEM_LD= @${CC} ${DEBUG} -Wl,--export-dynamic -o ${.TARGET} ${SYSTEM_OBJS} vers.o -pthread (sys/platform/vkernel64/conf/Makefile:23) — libc resolves exit, sigaction, closefrom, … and reboot.
• nm/readelf on the built kernel.debug (nm_reboot_proof.txt): U reboot / reboot@DF404.0 UND — a dynamic libc import.
• shutdown.c:54 includes <unistd.h> (host header, via INCLUDES+= -I/usr/include, kern.pre.mk:68), which declares int reboot(int); at /usr/include/unistd.h:594 — the same declaration conflict my interposer hit.

2. The call executes (certain — three cores)

The initproc == NULL window is the SYSINIT sliver between initshutdown (SI_BOOT2_PROC0, SI_ORDER_ANY — runs after the two SI_ORDER_FIRST entries of its subsystem) and create_init (SI_SUB_CREATE_INIT — the immediately following subsystem; kernel.h has no subsystem in between). Ordinary signal timing cannot land there (signal→ithread latency ≫ sliver; the DF-5661 runs showed hundreds of SIGTERMs all executing shutdown_intr after create_init), but a same-uid kill-storm (a forked child spamming kill -TERM at full rate, which any local user of the vkernel's uid can do) squeezes hits into the window. Three runs died with SIGILL and every core shows:

#1  0x0000000000721280 in ?? () at shutdown.c:97   <- reboot(RB_POWEROFF)
#0  0x00007fffffdfe000 (ld.so resolver)  /  libc umtx_wakeup

i.e. shutdown_intr's reboot(RB_POWEROFF) executed and entered the host libc reboot path; the process died inside ld.so/libc because the storm re-entered signal handlers mid-PLT-resolution/mid-libc-prologue — a trigger artifact. The tripwire variant (interposed reboot() that logs, silences the storm, masks signals, then issues syscall(55, howto)) never got a clean in-window shot before collateral death; that is a rig limitation, not a mitigation: nothing in the kernel rejects the call (the vkernel runs as root; reboot(2)'s only gate is privilege).

3. End-to-end host reboot

Not completed in the lab: each time the branch fired, the storm's own re-entrancy killed the process inside libc before the syscall retired. On a production host a single lucky SIGTERM (no storm, no re-entrancy) completes reboot(2) unimpeded. Severity therefore accounts for the narrow window (AC:H) but the impact ceiling is the physical host.

Why not uid0

This is not a memory-corruption primitive: it is a wrong-context host syscall. The ceiling is host reboot/poweroff (availability catastrophe, potential data loss on every mounted filesystem of the host), not code execution. On the audit guest the "host" is the VM, so the identical call would cycle the VM.

Fix validation (fixed)

fix.diff (authored after verification, never applied to the read-only sys/ tree):

1. shutdown.c: gate ksignal(initproc, SIGUSR2) on init actually catching SIGUSR2 (ps_sigcatch, the kernel's own SIG_CATCH/SIG_DFL delivery criterion, kern_sig.c:2110-2146); else shutdown_nice(RB_POWEROFF | RB_HALT) — the in-kernel path.
2. kern_shutdown.c: shutdown_nice() gets the same gate (its blind ksignal(initproc, SIGINT) had the identical no-op defect).
3. kern_shutdown.c: shutdown_cleanup_proc() only calls kern_closefrom(0) when p == curproc — boot() entered from an ithread (which is what shutdown_intr is) has curproc == NULL and KKASSERTs at kern_descrip.c:1420 (hit live during validation: panic: assertion "p" failed in kern_closefrom).

Applied to the guest's /usr/src validation copy, kernel rebuilt:

• Baseline: storm trigger → shutdown.c:97 → host libc reboot (cores above); SIGTERM mid-boot → silent no-op (DF-5661).
• Patched: same storm trigger → tripwire silent, guest host never cycles; whenever shutdown_intr executes it takes the kernel path: boot() called on cpu#0 → system threads stopped → Uptime → The operating system has halted. → cpu halt, exiting vkernel → exit(EX_OK) → monitor exits (full transcript: DF-5661/run.fixboot.log). Bad behavior gone.

Environment

env.txt — DragonFly 6.5-DEVELOPMENT X86_64_GENERIC (guest host), VKERNEL64 built in-guest with the DF-5474 defsym workaround; rig lineage DF-5337/5579/5607 (fifo console, /vkroot.img, -n 2/-n 1 SMP variants).

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.