DF-3095 verdict — REPRODUCED (panic/DoS + snapshot-isolation break)

What was claimed

hammer_vfs_mount() copies rootvol->ondisk->vol0_next_tid into hmp->next_tid (sys/vfs/hammer/hammer_vfsops.c:731) without any validation. hammer_alloc_tid() (sys/vfs/hammer/hammer_transaction.c:162-181) increments that value with no wrap handling:

    if (hmp->master_id < 0) {
        tid = hmp->next_tid + 1;
        hmp->next_tid = tid + count;
    } else {
        tid = (hmp->next_tid + HAMMER_MAX_MASTERS) &
              ~(hammer_tid_t)(HAMMER_MAX_MASTERS - 1);
        hmp->next_tid = tid + count * HAMMER_MAX_MASTERS;
        tid |= hmp->master_id;
    }
    if (tid >= 0xFFFFFFFFFF000000ULL)
        hpanic("Ran out of TIDs!");

Default mounts have master_id = 0 (hammer_vfsops.c:396), i.e. the second branch. Since vol_crc is never verified (DF-3042), an 8-byte patch to the volume header controls this state fully.

How it was verified (guest, stock INVARIANTS kernel #0/#5, X86_64_GENERIC)

Variant 1 — panic (reproduced 1/1)

• tid_craft panic → vol0_next_tid = 0xFFFFFFFFFF000000 (header offset 0xF8/decimal 248, confirmed by offsetof against the real hammer_disk.h).
• mount_hammer /dev/vn0 /mnt succeeds ("mounted clean, no recovery needed").
• echo hello > /mnt/x → panic: hammer_alloc_tid: Ran out of TIDs!

Backtrace (panic.txt):

panic: hammer_alloc_tid: Ran out of TIDs!
hammer_alloc_tid() at hammer_alloc_tid+0xa7
hammer_alloc_objid() at hammer_alloc_objid+0x246
hammer_create_inode() at hammer_create_inode+0x365
hammer_vop_ncreate() at hammer_vop_ncreate+0xa8
vop_ncreate() at vop_ncreate+0x5b

The trigger is an ordinary open(O_CREAT) — reachable by any user with write permission on any directory of the mounted filesystem after a privileged mount of suspect media.

Variant 2 — wrap to 0 (reproduced 1/1, no panic, silent)

• tid_craft wrap → vol0_next_tid = 0xFFFFFFFFFFFFFFFF.
• Mount RW + write: no error anywhere. hammer history /mnt/b shows create_tid = 0x0000000000008010 on a filesystem whose TID space starts at 0x0000000100000000 (newfs sets next_tid to 1<<32).
• Snapshot leak proof: with T1 = hammer synctid = 0x0000000100008080 taken when only file a existed, then wrapping the (unmounted, re-mounted RW) image and creating file b (create_tid 0x8010), mount_hammer -T 0x0000000100008080 shows b inside the T1 snapshot (ls -l in run.log: a AND b, cat /mnt/b → BBB). Btree visibility is create_tid <= asof < delete_tid, so post-wrap records are visible in every historical asof view/snapshot of the filesystem, and sort before all real records for mirror/prune semantics.

Impact

• Panic variant: deterministic kernel DoS (mount of crafted media + any subsequent create; the mount itself reports success).
• Wrap variant: silent corruption of HAMMER's temporal model — new records leak into all snapshots (confidentiality: snapshot consumers see data that post-dates the snapshot), mirroring/pruning TID ordering assumptions break.
• Preconditions: privileged mount of attacker-crafted media (root or physical access), matching the DF-3040/3067/3068 family bar.

Fix validation

fix.diff (authored against the read-only sys/ tree, git-apply clean) rejects vol0_next_tid >= 0xFFFFFFFFFF000000ULL at mount time (ERANGE, alongside the existing vol_version check at hammer_vfsops.c:677-683). Applied to the guest's /usr/src copy, make nativekernel KERNCONF=X86_64_GENERIC, reboot:

• baseline (stock): panic variant → panic (above).
• patched kernel: both panic and wrap variants → mount: Result too large, console mount rejected vol0_next_tid ffffffffff000000, guest stays up (fix_run.log).
• regression: stock newfs_hammer image mounts RW, file create/sync/umount normal on the patched kernel (fix_run.log).

Not this bug

vol0_next_tid write-back during flusher finalize is a different sink; only the mount-time load is addressed here (the MNT_UPDATE path never reloads the field).

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.