Volume-header CRC (vol_crc) is never verified — hammer_crc_test_volume has zero callers; all mount-time header consumption is integrity-unchecked

Summary

hammer_install_volume validates only vol_signature, fsid match, duplicate vol_no and root vol_no; the root volume's vol_crc field is loaded into kernel memory but never checked — hammer_crc_test_volume() is defined and referenced nowhere else in the kernel (tree-wide grep). Everything downstream of mount — vol_no, vol_count, vol_version, vol_buf_beg/vol_buf_end, vol0_blockmap[] (including the undo map that feeds DF-3040), vol0_undo_array[], vol0_btree_root, vol0_stat_* — is consumed with zero integrity gate. For a malicious crafter this changes nothing (CRC is forgeable), but for the corruption/robustness threat model the missing gate means random media corruption is interpreted as trusted metadata instead of failing the mount; it is also the reason the DF-3040 PoC needed no CRC fixup. Layer1 freemap CRCs are verified on blockmap paths and B-Tree nodes at load — the volume header is the one unchecked anchor structure. Fix: verify the header CRC after the signature check (row diff). Not applicable to Phase V (hardening).

Timeline

• 2026-09-02 Discovered during pass-2 audit of hammer_ondisk.c (GLM 5.3).