DF-2640 — PoC evidence pack

Unguarded hammer2_chain_dirent_test() calls in the hammer2 xop lookup loops: the first dereference of a corrupted (NULL-data) chain on every resolve/unlink/rename — kernel NULL-deref panic, not remediated by DF-2617's fix.

sys/vfs/hammer2/hammer2_xops.c feeds freshly-locked chains from hammer2_chain_lookup() straight into hammer2_chain_dirent_test() at xops.c:282 (nresolve), :368 (unlink), :610 (nrename source), :771 (nrename target-overwrite), with only chain != NULL checked. hammer2_chain_dirent_test() (chain.c:5768-5793) dereferences chain->data->ipdata (INODE entries, :5775) and chain->data->buf (long-named DIRENT entries, :5784) with no chain->error and no chain->data check. With the (still live) DF-2617 primitive — bref.data_off == 0 on a data-requiring chain makes hammer2_chain_load_data() early-return success (chain.c:938-939), leaving chain->data == NULL, chain->error == 0 — this is a guaranteed NULL-deref. DF-2617's verified fix.diff only guards the mount-path consumers (vfsops label scan, iocom); it arms chain->error for these types but nothing on the xop lookup path reads it, so this crash survives DF-2617's fix.

Key reachability detail proven on the guest: entries with names > 64 bytes store their name in the dirent's data block, so dirent_test takes the bcmp(chain->data->buf, …) branch — this xop-backend deref is the first touch of the corrupted chain (short-named dirents are bref-embedded and never touch chain->data).

Reproduce

# host (pack dir): build base image in guest, forge on host, push
sh build.sh
# guest (root), stock INVARIANTS kernel #0:
sh /root/poc/df2640/trigger_U.sh   # mounts U.img, then:
                                  # su -m nobody -c 'rm /mnt/h2/pub/<80*p>'
# expected: Fatal trap 12, fault VA 0x0, "Stopped at bcmp+0xf0: movq (%rdi),%r8",
#           current process = Idle (xop backend thread), db> prompt, guest dead

With fix.diff applied (kernel #1, built in-guest with make -j6 nativekernel && make installkernel), the same trigger returns rm: …: No such file or directory (clean ENOENT), the guest stays up (fix_run.log), and a full regression on the uncorrupted image (long+short names, create/cp/mv/ln/rm as nobody, umount) passes.

Threat model: root mounts a crafted hammer2 image (USB stick / untrusted volume); any unprivileged user with write permission on a directory (here nobody, uid 65534, mode-777 pub/) then panics the machine with a single rm. Same class/triggers as the verified DF-2616/DF-2617 pack forgers (volhdr→sroot→PFS walk, CHECK_NONE ancestors, volhdr CRC32C recompute).

• Full narrative: VERDICT.md
• Machine verdict: verdict.json (schema: audit/persist_poc.py)
• Verified fix: fix.diff (chain.c dirent_test guards + xops.c hardening for the DF-2641 latent sinks; validated on a rebuilt kernel)
• Baseline crash: panic.txt (serial console, stock kernel #0); panic_ls_variant.txt — en-passant observation of the frontend readdir sink (vnops.c:727 hammer2_xop_gdata()->buf, "from ls", memcpy NULL-source) on the same forged image; that one belongs to hammer2_vnops.c, not this file.

DF-2640 — VERDICT

Finding

sys/vfs/hammer2/hammer2_xops.c passes chains returned by hammer2_chain_lookup() directly to hammer2_chain_dirent_test() on four backend paths — nresolve (xops.c:282), unlink (xops.c:368), nrename source lookup (xops.c:610), nrename target-overwrite scan (xops.c:771) — checking only chain != NULL. hammer2_chain_dirent_test() (hammer2_chain.c:5768-5793) has no chain->error guard and no chain->data guard:

• INODE entries: ripdata = &chain->data->ipdata; ripdata->meta.name_len (chain.c:5775-5776)
• long-named DIRENT entries (>64 bytes, name lives in the dirent data block): bcmp(chain->data->buf, name, name_len) (chain.c:5783-5784)

Combined with the DF-2617 primitive (hammer2_chain_load_data() early-return at chain.c:938-939 for data_off == 0 → data == NULL, error == 0 — still live in this tree), the very first name-test on such a chain faults.

Delta vs DF-2617 (why this is a separate finding): DF-2617 verified mount-path sinks (vfsops.c:1309/1560, iocom.c:311) and its fix.diff arms chain->error = EIO for data-requiring types. But neither the xop lookup loops nor dirent_test itself ever check chain->error, and pre-fix the error is 0 anyway — so rm/mv/name-lookup of a corrupted entry panics before and regardless of DF-2617's fix. This is also distinct from DF-2619 (dirent namlen vs chain->bytes OOB read inside dirent_test): here the chain has no data at all.

Reproduction (baseline, stock INVARIANTS kernel #0)

Forge (see forge_df2640.py): base image with /pub (mode 777) containing a file whose 80-byte name forces a data-block-backed DIRENT; zero that DIRENT bref's data_off; CHECK_NONE the covering ancestors (pub-inode bref, the INDIRECT bref covering it, PFS bref, sroot brefs); recompute volhdr CRC32Cs.

Trigger trigger_U.sh: mount, then su -m nobody -c 'rm /mnt/h2/pub/<80*p>'.

Observed (panic.txt, serial console):

Fatal trap 12: page fault while in kernel mode
cpuid = 4; lapic id = 4
fault virtual address   = 0x0                <-- chain->data == NULL (buf @ union offset 0)
fault code      = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff80bcb8f0
current process     = Idle                <-- xop backend thread (h2xop-testvol)
Stopped at      bcmp+0xf0:      movq (%rdi),%r8
db>

• bcmp with %rdi == 0 is exactly bcmp(chain->data->buf, name, 80) (chain.c:5784) called from hammer2_xop_nresolve (xops.c:282) — current process = Idle proves the crash is in the kernel xop backend thread, not a user process.
• The rm executes as nobody (uid 65534) in a mode-777 directory — unprivileged post-mount trigger, identical threat model to DF-2616/2617.
• En passant (panic_ls_variant.txt): a prior run that did ls first crashed in the frontend readdir consumer instead (memcpy NULL-source, "from ls", vnops.c:727 hammer2_xop_gdata()->buf) — same primitive, different file; recorded for the vnops.c owners.

Exploitability ceiling

The fault is a read at the fixed address NULL + 0 through a bcmp of kernel buffers — a deterministic kernel NULL-deref panic (local DoS). The write-side variants of the class (e.g. bzero(wipdata->filename) at xops.c:672 after a modify that chain.c:1467 lets "succeed" with NULL data) are likewise fixed-offset (0x100) faults; the NULL page is not mappable by userspace on DragonFly/x86_64 (VM_MIN_ADDRESS). No path from this primitive to attacker-addressed memory was found — impact ceiling is panic/DoS, matching DF-2617's rating (Medium).

Fix validation (kernel #1, make -j6 nativekernel, in-guest)

fix.diff (git-apply-able against the read-only tree):

1. hammer2_chain_dirent_test(): return 0 (no match) for chain->error || chain->data == NULL in the INODE branch and in the

   64-byte DIRENT branch. Short-named dirents (name embedded in bref.check.buf, legitimately data_off == 0) remain matchable — this is required for the filesystem to keep working.

2. hammer2_xops.c hardening (the DF-2641 latent sinks, same validated build): guards at unlink:402 (else if (chain->data) … error out), nrename:543 (ip4 type read — previously no error check at all), post-modify data == NULL checks in the nrename INODE/DIRENT adjust blocks, error == 0 && chain->data != NULL condition on the iparent update (nrename:755), and a post-modify parent->data check in hammer2_xop_inode_chain_sync (xops.c:1636).

Results (fix_run.log, fix_build.log):

• Same trigger_U.sh on kernel #1: MOUNT_RC=0, rm: /mnt/h2/pub/pppp…: No such file or directory, RM_RC=1, no panic, guest up (baseline panic is gone).
• Regression on the uncorrupted base image as nobody: create/cp/mv/ln/rm of long- (80-byte) and short-named files in the 777 dir, read-back, clean umount — all pass (REGRESSION_OK).
• Guest left clean via vm.sh reset with-src.

Bottom line

reproduced / panic (Medium, crafted-image local DoS via unprivileged post-mount trigger). The finding is real, first-touch (unshadowed — for

64-byte names the xop-backend dirent_test call is the first dereference), and survives DF-2617's fix; fix.diff removes it cleanly with no regression.