=== DF-0834 BASELINE RUN (unpatched #0 kernel) ===
Command: cd /root/df0834 && sh trigger.sh  (foreground over ssh, timeout 35)
Image: df0834.img (UFS1/FFS, 4MB; A(ino=4)<->B(ino=5) cyclic .. forged)

=== output streamed before the guest wedged ===
=== DF-0834 trigger 06:53:31 ===
uname: DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026     root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC
vn device: vn4
=== mounted; ls -li ===
total 12
4 drwxr-xr-x  2 root  wheel  512 Jul 11 06:53 A
5 drwxr-xr-x  2 root  wheel  512 Jul 11 06:53 B
3 drwxr-xr-x  2 root  wheel  512 Jul 11 06:53 S
=== launching mv (background) ===
mv pid=918 at 06:53:31
<trigger.sh then entered its first "sleep 1; ps @+1s" cycle; the ssh session
stalled here — the guest became COMPLETELY UNRESPONSIVE to ssh within ~1
second of the mv being launched. The outer `timeout 35` killed ssh at 35s.>

=== analysis ===
The rename(2) "mv S A/S_moved" enters ufs_rename -> ufs_checkpath(source=S,
target=A). ufs_checkpath (sys/vfs/ufs/ufs_lookup.c:1130-1166) walks A's ".."
chain in an unbounded for(;;) loop:
  A's ".." = ino 5 (B), B's ".." = ino 4 (A)  [forged cycle]
  => A -> B -> A -> B -> ... forever

Each iteration calls vput(vp)/VFS_VGET(...), and the tight cycling through the
vnode layer monopolizes vnode interlock + mount vnode-list lock, wedging the
ENTIRE system (not just the calling thread). sshd cannot fork/exec because
even root-fs vnode ops contend on the same global locks. The guest must be
hard-reset (SIGKILL on the qemu process); `vm.sh down` (clean shutdown)
hangs indefinitely.

No kernel panic — the serial console (boot.log) shows the login prompt
unchanged; the system is hung, not crashed. This is a hard DoS: the only
recovery is a reboot, and SIGKILL cannot stop the spinning thread.

Contrast with DF-0824 (ext2): there the hang was observable per-process (mv
at 100% CPU, SIGKILL-proof) but the system stayed marginally responsive.
UFS checkpath wedges harder because VFS_VGET cycling contends more heavily
on the vnode layer.