DF-2635 — iroot meta.inum desync walks off the inum hash in hammer2_inode_drop

What

hammer2_inode_get(pmp, NULL, 1, -1) hashes the freshly-created PFS root inode under inumhash(pmp, 1) (hammer2_inode.c:933, 954-977). Afterwards, two mount paths overwrite the inode's meta wholesale from media:

• hammer2_pfsalloc: iroot->meta = ripdata->meta; (hammer2_vfsops.c:456)
• hammer2_vfs_root: pmp->iroot->meta = *meta; (hammer2_vfsops.c:1975)

If the on-media PFS-root meta.inum is not 1 (crafted or corrupted image), the in-memory inode now sits on the wrong inum-hash bucket. At unmount, hammer2_inode_drop() computes the bucket from the current ip->meta.inum (hammer2_inode.c:617) and walks the wrong list:

xipp = &hash->base;
while (*xipp != ip)            /* hammer2_inode.c:624 */
        xipp = &(*xipp)->next;

next is the first field of struct hammer2_inode, so once the walk falls off the end, xipp degenerates to NULL and *xipp reads address 0 — NULL-deref panic during umount (the drop is reached from hammer2_vfsops.c:707-711 where unmount drops the last iroot ref).

Secondary effect: hammer2_inode_lookup(pmp, 1) can no longer find iroot (its meta.inum no longer matches what lookups compare) while lookups of the media inum find nothing either (iroot is on bucket 1) — in-memory inode aliasing / inconsistent namespace semantics until the wedge.

Reproduce (guest, root)

python3 forge_2635.py h2base.img craft2635.img   # host: inum 1 -> 0x42
scp craft2635.img dfbsd:/root/poc/df2635/
sh run.sh

run.sh: vnconfig + mount_hammer2 /dev/vn1@testvol /mnt/h2635 (RW), ls, write+cat a file, sync, then umount.

Expected

Mount/ls/write/sync all succeed; umount panics:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
Stopped at hammer2_inode_drop+0x1e3: movq (%rax),%rdx     (from umount)

Observed verbatim on the stock kernel — see panic.txt / run.log.

Fix

Keep the hashed inum stable across the meta overwrites and harden the drop-side walk — see fix.diff.

DF-2635 — VERDICT

Status: reproduced (impact: panic, confidence: certain).

Narrative

Forged image identical to DF-2636's recipe except the flipped field is meta.inum (inode block +0x58), changed from 1 to 0x42 — type stays 1 (DIRECTORY) so the mount is fully functional.

Guest run (stock INVARIANTS kernel, DragonFly 6.5-DEVELOPMENT #0):

1. mount_hammer2 /dev/vn1@testvol /mnt/h2635 — succeeded (console: hammer2_mount: ... rdonly=0, no recovery needed).
2. ls -la /mnt/h2635, echo hello > /mnt/h2635/f, cat, sync — all succeeded (the RW mount is fully usable; iroot's wrong meta.inum is not consulted on these paths).
3. umount /mnt/h2635 — panic, exactly the predicted walk-off:

Fatal user address access from kernel mode from umount at ffffffff80960353
Fatal trap 12: page fault while in kernel mode
fault virtual address      = 0x0
instruction pointer        = 0x8:0xffffffff80960353
current process            = 852 (umount)
Stopped at hammer2_inode_drop+0x1e3: movq (%rax),%rdx

fault virtual address = 0x0 confirms the degeneration: struct hammer2_inode.next is at offset 0, so the runaway walk xipp = &(*xipp)->next collapses to NULL and the loop condition *xipp reads address 0. The trap is inside hammer2_inode_drop called from the umount path — the exact code at sys/vfs/hammer2/hammer2_inode.c:624-625, with the wrong bucket chosen at :617 because iroot->meta was overwritten post-hash by hammer2_vfsops.c:456 (iroot->meta = ripdata->meta).

Pre-conditions / trust boundary

Crafted or checksum-forged hammer2 image (mount requires root — same boundary as DF-0763/DF-2616/DF-2624 family). All media bytes are otherwise structurally valid; only meta.inum != 1 on the PFS root inode.

Exploit ceiling

Controlled NULL-pointer read panic (DoS) at unmount, plus in-memory inode aliasing/lookup inconsistency for the mount's lifetime (iroot unreachable by inum; a second inode for the same media chain can be created by inum-based lookups such as nlookupdotdot). No write primitive.

Fix validation

fix.diff (a) preserves meta.inum = 1 across both wholesale meta overwrites in hammer2_vfsops.c (the inode is hashed under 1), and (b) hardens hammer2_inode_drop's removal walk against falling off the list (while (*xipp && *xipp != ip) + warn on desync). Single-fix kernel built with make nativekernel, installed, rebooted: the same forged image mounts, is usable, and unmounts cleanly (fix_run.log) while the baseline panicked in the same session.