DF-0762 — NULL deref in hammer2_chain_lastdrop no-parent retry path

Bug: sys/vfs/hammer2/hammer2_chain.c hammer2_chain_lastdrop() — the no-parent else branch (where parent == NULL) has a 1→0-retry path that executes hammer2_spin_unex(&parent->core.spin) (old line 654), dereferencing NULL and releasing a spinlock that was never acquired in that branch. Result: kernel page-fault panic (local DoS) when the concurrent-ref race is won on a transiently-parentless chain during HAMMER2 topology teardown.

Severity: Medium (DoS only — NULL-deref at a fixed offset, no escalation path).

Files

• h2_churn.c — multi-thread HAMMER2 churn harness (create/delete/rename/mkdir/sync), run as the unprivileged user on a mounted HAMMER2 filesystem.
• setup_h2.sh — root-side: creates a HAMMER2 image (vnconfig+newfs_hammer2), mounts it at /h2test, chowns to maxx.
• build.sh — cc -O2 -pthread -o h2_churn h2_churn.c.
• run.sh — runs the churn harness.
• fix.diff — removes the bogus hammer2_spin_unex(&parent->core.spin) in the no-parent retry branch (the only correct, minimal change).
• VERDICT.md — full analysis, mechanism, reachability, fix validation.
• manifest.json — artifact catalog.

Reproduce

# root on guest: set up HAMMER2 image + mount + chown to maxx
ssh dfbsd '/bin/sh /root/poc/DF-0762/setup_h2.sh 2048'
# unprivileged: build + run the churn
ssh dfbsd-maxx 'cd /h2test && /root/poc/DF-0762/h2_churn 120 10 6 6'

Expected (bug present): under heavy churn the kernel may panic with a page-fault at a low address inside hammer2_chain_lastdrop (serial console / dfbsd-qemu/boot.log). The race is narrow; the bug itself is a static certainty at sys/vfs/hammer2/hammer2_chain.c:654 (parent is unconditionally NULL in the else branch).

Preconditions (acceptable mount-threat-model): a HAMMER2 filesystem image mounted by root (mount is root-only), made usable by the unprivileged user. The trigger itself (churn) is entirely unprivileged.

Impact ceiling

NULL-deref at a fixed low offset → pure DoS (panic). No attacker-controlled write content, no pivot — no privilege-escalation chain is derivable.

DF-0762 — NULL deref in hammer2_chain_lastdrop no-parent retry path

Verdict

REPRODUCED (code-level certain) — local DoS (kernel panic) on a HAMMER2 filesystem under churn. The NULL-deref is a provable static fact (not probabilistic); the only probabilistic element is winning the concurrent-ref-bump race that reaches the buggy retry line. The live race did not panic within bounded churn time, but the bug is unambiguous and the missing check is confirmed line-by-line below. Fix VALIDATED on a single-fix #1 kernel: offending line removed, patched kernel compiles/boots, identical hammer2 churn runs clean with no panic and no regression.

Mechanism (trigger → primitive → effect)

hammer2_chain_lastdrop() (sys/vfs/hammer2/hammer2_chain.c) is reached when a chain's refcount is dropping 1→0 (caller hammer2_chain_drop, line 357-359). At the topology-teardown tail of lastdrop:

• L577 parent = chain->parent; — parent may legitimately be NULL (a chain detached from the topology, or a PFS-root chain whose own parent is gone).
• L593 if (parent) { — the parent case. It correctly acquires hammer2_spin_ex(&parent->core.spin) at L594 before the cmpset, and releases it at L599 (retry) / L643 (success).
• L646 } else { — the No-parent case, where parent == NULL.
• L650 if (atomic_cmpset_int(&chain->refs, 1, 0) == 0) { — the 1→0 transition failed because a concurrent hammer2_chain_ref (atomic bump) raced refs 1→2 in the window. This is the retry path.
• L654 hammer2_spin_unex(&parent->core.spin); — BUG. In this else branch parent is NULL, and no parent spinlock was ever acquired in this branch. &parent->core.spin evaluates to NULL + offsetof(hammer2_chain, core) + offsetof(hammer2_chain_core, spin). core is the 2nd field of hammer2_chain (after hammer2_mtx_t lock, sys/vfs/hammer2/hammer2.h:325-326) and spin is the 1st field of hammer2_chain_core (hammer2.h:238-239), so the deref lands at NULL + sizeof(hammer2_mtx_t) — a low, unmapped address → page fault → kernel panic (DoS). The line is doubly wrong: it dereferences NULL and releases a spinlock that was never held.

Compare the parent retry (L599), which legitimately releases parent->core.spin because L594 acquired it. The no-parent retry is a copy/paste of that block without the corresponding acquire; it should only release the locks actually held in this branch — chain->core.spin (L655) and chain->lock (L656) — which were acquired earlier in lastdrop.

Reachability / threat model

• parent == NULL on entry to the teardown tail is routine: it happens for any chain detached from the topology whose refs are being dropped (e.g. a parent chain that lost its last child via the recursive rdrop return at L698 and itself has no parent), and for PFS-root chains during unmount.
• The cmpset at L650 fails when a concurrent hammer2_chain_ref bumps refs 1→2. The kernel itself acknowledges such races exist (h2race1 detection kprintf at hammer2_chain.c:403).
• Trigger (unprivileged): once a HAMMER2 filesystem is mounted (root precondition — an admin has mounted a filesystem image, an acceptable mount-threat-model precondition), heavy concurrent create/delete/rename/sync churn by an unprivileged user drives blocktable maintenance and topology teardown, transiently producing parentless chains whose last-drop races a concurrent ref → the buggy retry fires → panic.

A NULL-deref at a fixed low offset is a pure DoS — no escalation chain is possible (no attacker-controlled write content, no pivoting). This finding is DoS only; there is no uid=0 path.

Reproduction attempt (live)

• Built h2_churn (multi-thread create/delete/rename/mkdir-tree/sync storm) as the unprivileged user maxx on a 2 GB HAMMER2 image mounted at /h2test.
• Ran ~3.5 min total of aggressive churn (4/2/2 → 8/4/4 → 10/6/6 threads) on the unpatched #0 kernel. No panic fired: the race window (cmpset losing to a concurrent ref bump on a transiently-parentless chain) is genuinely narrow.
• This is expected; the bug is nonetheless a static certainty — once the else-branch retry is reached, parent is unconditionally NULL and L654 unconditionally faults. Per the run-brief, a deterministic code-level confirmation is acceptable when the live race is too narrow; the line-by-line trace above is that confirmation.

Fix

fix.diff removes the bogus hammer2_spin_unex(&parent->core.spin); at the no-parent retry (old L654) and clarifies the comment. The no-parent branch never acquires parent->core.spin (parent is NULL), so removing its release is the only correct, minimal change. The remaining two releases (chain->core.spin, chain->lock) are legitimate (held since earlier in lastdrop).

Fix validation (Phase 8)

• Baseline (#0, unpatched): kern.version = 6.5-DEVELOPMENT #0, Thu Jul 2 06:02:54 UTC 2026. Bug line hammer2_spin_unex(&parent->core.spin); present at L654. (Live race did not panic in bounded churn — narrow.)
• Applied fix.diff to in-guest /usr/src; line confirmed removed.
• Built single-fix kernel make -j6 nativekernel KERNCONF=X86_64_GENERIC (warm obj; hammer2_chain.o recompiled, kernel.debug relinked; rc=0; options HAMMER2 builds hammer2 into the kernel, so the rebuilt kernel.stripped carries the fix — no module reinstall needed).
• Installed /boot/kernel/kernel ← kernel.stripped, rebooted.
• Patched (#1): kern.version = 6.5-DEVELOPMENT #1, Thu Jul 9 12:55:57 UTC 2026. Bug line gone; comment updated.
• Re-ran the identical churn workload (./h2_churn 120 10 6 6) as maxx: no panic, no regression, BG_DONE rc=0, guest stayed up.
• Verdict: the offending NULL-deref line is removed by construction and the patched kernel is functionally clean; the live race is too narrow to serve as a panic before/after, so validation rests on the code-level removal (clean before/after of L654) + compile/boot + no-regression churn.

PoC changes

• Authored the evidence pack from scratch (no prior PoC folder existed): h2_churn.c (multi-thread HAMMER2 churn harness), setup_h2.sh (creates a HAMMER2 image via vnconfig+newfs_hammer2, mounts, chowns to maxx), build.sh, run.sh, fix.diff, this VERDICT.md, manifest.json, full logs.
• setup_h2.sh uses DragonFly's vnconfig (not Linux mdconfig) on vn0.

Reproduce

ssh dfbsd     # root: set up the hammer2 image + mount
  /bin/sh /root/poc/DF-0762/setup_h2.sh 2048     # creates /h2test, chowns to maxx
ssh dfbsd-maxx  # unprivileged: run the churn
  cd /h2test && /root/poc/DF-0762/h2_churn 120 10 6 6
# watch dfbsd-qemu/boot.log for a fatal-trap/page-fault in hammer2_chain_lastdrop
# (the race is narrow; the bug is a static certainty at hammer2_chain.c:654)