โฌข DragonFlyBSD Kernel Audit
DF-0824 / run.log
โ† back to finding โ†“ download raw
=== DF-0824 BASELINE (unpatched #0 kernel) โ€” trigger output ===
guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026  x86_64
image: /root/df0824.img (sha256 b3124c44966b4e68e10233092ef2c1e307de91aec21a4196852f1db78204fdf1)
trigger: sh /root/df0824_trigger.sh /root/df0824.img

=== trigger.sh output ===
=== DF-0824 trigger ===
image: /root/df0824.img
vn device: vn4
mounted vn4 at /mnt/df0824
total 34
drwxr-xr-x  6 root  wheel   1024 Jul 11 00:40 .
drwxr-xr-x  1 root  wheel   0    Jul 11 00:44 ..
drwxr-xr-x  2 root  wheel   1024 Jul 11 00:40 A
drwxr-xr-x  2 root  wheel   1024 Jul 11 00:40 B
drwxr-xr-x  2 root  wheel   1024 Jul 11 00:40 S
drwx------  2 root  wheel   12288 Jul 11 00:40 lost+found
rename pid: 1140 (in kernel; expect hang on unpatched kernel)
RESULT: HANG (rename did not return within 5s -> ext2_checkpath infinite loop)

=== stuck mv process (PID 1141) โ€” kernel-stuck, SIGKILL-proof ===
   PID STAT        TIME UCOMM
  1141 R3       6:53.27 mv
  (R3 = RUNNING on CPU 3, not sleeping; wchan = "-" (no wait channel))

=== kill -9 1141 did NOT stop the process ===
The kernel-stuck thread cannot be interrupted by SIGKILL. CPU TIME accumulates
monotonically:
   t=0:53  (just after trigger)
   t=1:39  (after first kill -9 attempt)
   t=1:53
   t=6:53  (several minutes later)
This is the signature of an uninterruptible infinite loop in kernel context โ€”
the `for(;;)` walk of the `..` chain in ext2_checkpath() (ext2_lookup.c:1212).

=== mechanism ===
ext2_rename(fvp=/mnt/S, tdvp=/mnt/A, ...) at ext2_vnops.c:826 calls
ext2_checkpath(ip=S_inode, dp=A_inode, cred) when doingdirectory && newparent.
The for(;;) loop walks A's `..` chain:
  iter 1: vp=A, read A's `..`=B(ino14). B != source(ino12), B != root(ino2). vget(B).
  iter 2: vp=B, read B's `..`=A(ino13). A != source(ino12), A != root(ino2). vget(A).
  iter 3: vp=A, ... -> infinite loop (A<->B cycle, neither is source nor root).

No depth limit, no cycle detection, no signal-pending check at ext2_lookup.c:1212-1241.

The crafted image is impossible to create online (mkdir/rename always set `..`
to the true parent; hard-linking directories is forbidden). It requires offline
image editing (debugfs/raw byte patching) โ€” the threat model of a malicious ext2
image mounted by an admin, or a user-mounted image via vfs.usermount=1.