panic: sysctl_debug_panic
cpuid = 2
Trace beginning at frame 0xfffff80118787778
stack_guard_panic2() at stack_guard_panic2 0xffffffff802cd040
stack_guard_panic2() at stack_guard_panic2 0xffffffff802cd040
sysctl_root.isra.5() at sysctl_root.isra.5+0x166 0xffffffff80683d06
userland_sysctl() at userland_sysctl+0x111 0xffffffff806840a1
sys___sysctl() at sys___sysctl+0x74 0xffffffff80684204
syscall2() at syscall2+0x11e 0xffffffff80bd6a0e
boot() called on cpu#2

syncing disks...
[hangs here indefinitely]

---
This panic was forced via `sysctl -w debug.panic=1` ON THE WEDGED GUEST
(race between sys_mount hammering and kldunload churn of fuse.ko) in
order to capture thread state. The panic is NOT the vulnerability's
crash signature - the vulnerability's manifestation on the stock kernel
is an irrecoverable kernel deadlock (see run.log). The significance of
this capture: even the crash path wedges - "syncing disks..." never
completes because the crash-dump sync deadlocks on the same corrupted
mount/syncer state, so no vmcore is produced and the guest has to be
hard-killed. Serial console: dfbsd-qemu/boot.log, 2026-09-03 ~10:31 UTC.

Kernel: DragonFly 6.5-DEVELOPMENT #0 (stock INVARIANTS) x86_64.