DF-3223 — HAMMER1 prune_check_nlinks() NULL-deref: forged on-disk

inode record with data_offset == 0 → cursor->data->inode.nlinks

kernel panic on hammer prune / HAMMERIOC_PRUNE

Root cause (two-part)

1. hammer_btree_extract() sets cursor->data = NULL (sys/vfs/hammer/hammer_btree.c:705) and then, when the leaf's data_offset == 0, returns success (0) leaving the NULL in place (hammer_btree.c:728-731) — the early return happens before the CRC gate, so no CRC forging of the payload is needed.
2. prune_check_nlinks() (sys/vfs/hammer/hammer_prune.c:321-350) treats hammer_btree_extract_data(cursor) == 0 as "data available" and immediately reads cursor->data->inode.nlinks (hammer_prune.c:330-332). With data_offset == 0 that is a load from absolute address 0x48 (nlinks sits at offset 72 of struct hammer_inode_data, hammer_disk.h:886-901).

Reached for every live (delete_tid == 0) HAMMER_RECTYPE_INODE record that the prune scan does not delete — i.e. on any HAMMER1 filesystem whose on-disk inode record was corrupted or forged, the moment anyone runs hammer prune / hammer cleanup (or issues HAMMERIOC_PRUNE directly).

Build (guest, root; cc 8.3 in-base)

cc -O -o patch_inode patch_inode.c
cc -O -I/usr/src/sys/vfs/hammer -o trigger_prune trigger_prune.c

Setup (root, once; DF-3187 harness style)

dd if=/dev/zero of=/home/maxx/h1.img bs=32k count=0 seek=327680   # 10G sparse
vnconfig -c -S 10g /dev/vn0 /home/maxx/h1.img
newfs_hammer -f -L test /dev/vn0          # version 7 (iscsi crc)
mount_hammer /dev/vn0 /mnt
echo hello > /mnt/f1
hammer synctid /mnt quick
umount /mnt && vnconfig -u vn0

./patch_inode /home/maxx/h1.img
# found live inode leaf @off=554205184: objid=000000010000051d loc=00000001
#   data_off=9000000021800250 data_len=128 -> 0
# patched node @off=554205184 (crc algo iscsi/v7)

vnconfig -c -S 10g /dev/vn0 /home/maxx/h1.img
mount -t hammer /dev/vn0 /mnt              # RW mount (prune rejects ronly)

Run (root — HAMMERIOC_PRUNE is caps_priv_check-gated)

./trigger_prune /mnt

Expected / observed (stock kernel #0 Jul 2 2026)

Fatal trap 12, fault virtual address 0x48, supervisor read data, page not present:

Stopped at hammer_ioc_prune+0x37f: cmpq $0,0x48(%rax)

— the literal compiled form of cursor->data->inode.nlinks (prune_check_nlinks is static and inlined). Reproduced 3/3 from fresh vm.sh reset with-src cycles; guest dead every time (panic.txt, run.log, run.2.log, run.3.log).

Expected / observed (kernel #2 + fix.diff)

ioctl returned 0, scanrecords=6 rawrecords=1 bytes=128, 0 Fatal trap in /var/log/messages, filesystem still fully functional (create/read/remove on /mnt, clean umount), guest up (fixrun.log).

Threat model

Privileged trigger + untrusted media: the forged image is the attacker input (removable disk / forensic image / mirrored stream); mounting it is root, and hammer cleanup runs hammer prune on configured PFSs nightly. Same gate as DF-0910 (Medium). No write primitive: the deref address is the fixed struct offset 0x48 — DoS only. Forged data_offset != 0 variants of this same call site additionally give the DF-3187-class wild kernel-read walk (CRC engine reads data_len bytes at the forged buffer pointer) — read-only as well.

Path

sys/vfs/hammer/hammer_prune.c:330-332 (missing NULL check), sys/vfs/hammer/hammer_btree.c:705+728-731 (extract returns 0 with cursor->data == NULL), sys/vfs/hammer/hammer_disk.h:886-901 (nlinks @ 0x48), sys/vfs/hammer/hammer_ioctl.c:72+78-84 (SYSCAP_NOVFS_IOCTL gate on HAMMERIOC_PRUNE).

DF-3223 VERDICT — reproduced (panic, 3/3) and fix validated

Finding. prune_check_nlinks() in sys/vfs/hammer/hammer_prune.c dereferences cursor->data->inode.nlinks at line 332 immediately after hammer_btree_extract_data(cursor) returns 0 at line 330 — but hammer_btree_extract() (sys/vfs/hammer/hammer_btree.c:681-776) deliberately returns 0 with cursor->data == NULL when the on-disk leaf element carries data_offset == 0 (it stores NULL at :705 and early-returns at :728-731, before the CRC test at :764-765 — so no payload CRC forging is even required). nlinks is at offset 0x48 of struct hammer_inode_data (hammer_disk.h:886-901), so the guard-less read is a load from absolute kernel address 0x48.

Reachability. hammer_ioc_prune() walks the whole B-Tree range in reverse (hammer_prune.c:146-250) and calls prune_check_nlinks() for every record it does not delete (:227). The helper fires on any live (delete_tid == 0) HAMMER_RECTYPE_INODE leaf (:326-329) — an ordinary filesystem object — so the only precondition is that one inode record on the mounted HAMMER1 filesystem is corrupted/forged to have data_offset == 0. Trigger: hammer prune / hammer cleanup or a direct HAMMERIOC_PRUNE ioctl; the ioctl is privilege-gated (caps_priv_check(SYSCAP_NOVFS_IOCTL), hammer_ioctl.c:72,78-84), so the threat model is untrusted filesystem media + root-triggered maintenance — identical to DF-0910/DF-3167. Upstream master (github.com/DragonFlyBSD/DragonFlyBSD, checked 2026-09-08) contains the identical unguarded dereference; the file is frozen since 2008 ($DragonFly: hammer_prune.c,v 1.19 2008/09/23).

Reproduction (stock kernel #0 Jul 2 06:02:54, fresh cycles). Adapted the DF-3187 offline patcher (patch_inode.c) to rewrite data_offset (leaf element offset 48, hammer_btree.h:170-177) of the live inode record of /mnt/f1 (objid 0x10000051d, data_len 128) to 0 and fix the B-Tree node CRC (iscsi/v7 auto-detected). trigger_prune.c issues HAMMERIOC_PRUNE with HAMMER_IOC_PRUNE_ALL over the full PFS#0 key range on the RW-mounted forged image. Result, 3 out of 3 runs from fresh vm.sh reset with-src cycles:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x48
fault code              = supervisor read data, page not present
Stopped at  hammer_ioc_prune+0x37f: cmpq $0,0x48(%rax)

The faulting instruction is the compiled cursor->data->inode.nlinks test (static helper inlined into hammer_ioc_prune) — the code-to-fault correspondence is exact. Guest dead every time (panic.txt = full serial text of run 1; run.log / run.2.log / run.3.log).

Impact ceiling — why no uid=0 chain. The primitive is a kernel-mode read from the fixed address 0x48: the attacker controls only whether cursor->data is NULL (data_offset==0) — the deref address is a struct constant. Nothing is written, nothing is copied out, no attacker data reaches a control datum. The sibling variants of the same call site (forged data_offset != 0) hand the CRC engine and the nlinks read a wild buffer pointer (DF-3187 class) — still read-only walks with no copyout of the read data and no write. Both are DoS-grade; escalation does not exist for this bug. (Contrast DF-3167/DF-3168, which are write-capable.)

Fix validation. fix.diff adds the missing if (cursor->data == NULL) return; between the extract and the nlinks read (git-apply-able against sys/; git apply --check verified). Process note, documented for honesty: the first in-guest build (kernel

1 18:24:10) crashed identically because my initial hand-written diff

carried a wrong hunk header (@@ -327,6 +327,12 @@ for 9 context + 6 added lines); patch(1) "succeeded" while dropping the added return;, producing if (cursor->data == NULL) if (cursor->data->inode.nlinks) return; — and GCC constant-folded the NULL+nlinks load into the absolute movq 0x48,%rax seen at hammer_ioc_prune+0x65d. That crash is a PoC/diff artifact, and incidentally re-confirms the faulting source line. After restoring the pristine file and applying the corrected, mechanically generated fix.diff ("Hunk #1 succeeded at 329"), kernel #2 (Sep 8 18:43:09) was built (make -j6 nativekernel, BUILD_RC=0, installkernel, reboot) and the exact same PoC re-run:

ioctl returned 0 errno=0
scanrecords=6 rawrecords=1 dirrecords=0 bytes=128
grep -c "Fatal trap" /var/log/messages -> 0
ls /mnt -> f1 ; write/read/remove /mnt/f2 -> OK ; umount -> UMOUNT_OK

The prune completed its normal work over the forged filesystem (it even destroyed one legitimately-deleted record and freed 128 bytes), the forged inode record was skipped by the guard, zero traps, filesystem remained fully functional, guest stayed up. Baseline vs patched: identical input, opposite outcomes.

Classification. status=reproduced, impact=panic, confidence=certain. Privileged trigger (mount + prune) on attacker-supplied media → local kernel DoS; Medium severity consistent with DF-0910 calibration (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H, CWE-476).

Pass-2 negatives checked and killed (so the clean result has weight): no stat[]-array indexing exists (scalar counters only, hammer_ioctl.h:94-100); mod_tid != 0 divisions are well-defined (DF-0910 owns mod==0); nelms bounded [0,43690] at hammer_prune.c:67, 24*nelms ≤ 1,048,560 no int overflow (:101), kmalloc(0) legal (kern_slaballoc.c:888), single copyin (:104), pointer restored on exit (:262), PRUNE_ALL+nelms!=0 rejected (:80-81); localization pfs-bits rejected at :69-72 and only the inode's own pfs OR'd in (:87-93); EDEADLK retry re-initializes the cursor (:114, :253-255) — no double-free of cursor data refs; the flusher-wait unlock/lock idiom (:240-246) matches hammer_mirror.c:383-405 / hammer_inode.c:2889-2895 (hammer_lock_cursor's discarded return is the codebase-wide pattern; failures resurface as EDEADLK in the subsequent iterate); prune_delete's track=0 (:201-205) never touches vol0_next_tid; stat_realignments is a dead field. The DESTROY path's consumption of forged data_offset/data_len by hammer_blockmap_free (hammer_object.c:2512-2548 → hammer_blockmap.c:762-884, KKASSERT-only validation) is the DF-3167/3187 trust-the-leaf family at an out-of-file sink — not re-reported here.

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.