DF-2652 — freemap recovery marks the wrong 16K chunk (bit 18 dropped)

hammer2_freemap_adjust() (DORECOVER — mount-time crash recovery and the default-enabled dedup re-registration path) computes the bit-pair index of a 16KB chunk inside its 512KB bitmapq[] element with a 4-bit mask (& 15, freemap.c:1073) although elements hold 32 chunks. For every chunk in the upper 256KB of a 512KB element the fixup marks the chunk 256KB lower and leaves the real chunk marked FREE — the allocator then hands the still-live block to the next writer, producing overlapping allocations and silent cross-file data corruption.

Reproduce

Host:

python3 forge_2652.py base2651.img forge2652.img          # pair-clear + mtid bumps
python3 - <<'EOF'                                          # bleed variant (optional)
# set methods=0x00 (CHECK_NONE) on fileA's 24 DATA brefs in the indirect
# block at 0x2000000, recompute volhdr CRCs  (see build.sh for the exact code)
EOF

Guest (root):

vnconfig -c vn0 /tmp/forge2652.img
mount -t hammer2 /dev/vn0@testvol /mnt/h2t     # mounts fine (silent bug)
cp /tmp/fileB.bin /mnt/h2t/fileB; sync; umount /mnt/h2t; vnconfig -u vn0
vnconfig -c vn0 /tmp/forge2652.img             # remount
md5 /mnt/h2t/fileA                             # -> I/O error (default iscsi32 brefs)
dd if=/mnt/h2t/fileA bs=16k skip=16 count=4 | grep -ao "FILE[AB]-CHUNK-[0-9]*"
                                               # bleed variant: FILEB-CHUNK-000000..

Expected on stock kernel: fileA's 64K at 0x1c40000 overwritten by fileB (host-side: FILEB-CHUNK-000000 at disk offset 0x1c40000, fileA chunk 16-19 headers gone), fileA read → EIO (or FILEB content on the no-check variant). On the fixed kernel: fileA md5 matches the pristine fileA.bin, chunks 16..19 read FILEA-CHUNK-000016..19.

DF-2652 — wrong bitmap-pair index (& 15 vs 32 blocks) in hammer2_freemap_adjust()

status: reproduced | impact: dos (silent cross-file data corruption / file destruction; content bleed on no-check fs) | confidence: certain

Root cause

hammer2_freemap_adjust() computes the bit position of a 16KB chunk inside its 512KB bitmapq[] element as (freemap.c:1073):

start = ((int)(data_off >> HAMMER2_FREEMAP_BLOCK_RADIX) & 15) * 2;

Each element holds 32 chunks (5 bits: HAMMER2_BMAP_BLOCKS_PER_ELEMENT; see the allocator's own math at freemap.c:636 j = (offset / 8192) & 62 and bulkfree's staging at bulkfree.c:921-924 ((data_off & HAMMER2_BMAP_INDEX_MASK) >> BLOCK_RADIX) << 1, both of which use all 5 bits). The & 15 truncates the 5-bit block number to 4 bits, so for chunks 16..31 of every 512KB element (data_off bit 18 set) every DORECOVER fixup marks the pair of chunk (n-16) — 256KB lower, same element — instead of chunk n:

• the wrong (possibly free) chunk is set to 11 with bmap->avail -= 16K and voldata.allocator_free -= 16K (leak + accounting drift), and
• the actually-referenced chunk is left unmarked (00) → the allocator (hammer2_bmap_alloc scans for 00 pairs, freemap.c:694-705) hands the still-live block to the next allocation → overlapping allocations.

Reachable with no crafted image at all from either of the two DORECOVER callers: * mount-time crash recovery (vfsops.c:2234/:2325) — "Updates to the free block table are allowed to lag flushes by one transaction" (vfsops.c comment): any crash with unflushed allocations whose blocks sit in the upper 256KB of a 512KB element (~50% of blocks) are mismarked on the next mount; * the dedup re-registration path (chain.c:1610-1627, dedup_enable=1 by default, vfsops.c:71).

The PoC forges the crash-recovery condition deterministically for one fileA chain (X0 = 0x1c40000): its 4 bit-pairs are cleared 11→00 in the on-disk leaf and fileA's ancestry mirror_tids are bumped above freemap_tid so recovery re-adjusts them.

Decisive run (stock INVARIANTS kernel #0)

1. Mount forged image (mount succeeds — the mismark is silent).
2. cp fileB.bin /mnt/h2t/fileB (1.5MB, 24×64K unique chains); sync; umount.
3. Host-side inspection of the post-run image (after2652.img):

disk@X0 (0x1c40000): b'FILEB-CHUNK-000000-...'        <- fileB chain 0 landed ON X0
FILEA chunk 16..19 header on disk: NOT FOUND           <- fileA's block overwritten
FILEB chunk 0..3 header on disk: 0x1c40000..0x1c4c000  <- the overlapping allocs
leaf: bmap[7] avail 0x200000 -> 0x80000                <- accounting follows the lying bitmap

4. Remount + md5 /mnt/h2t/fileA → I/O error (fileA's iscsi32 CRC no longer matches because its live block was overwritten by fileB) — the victim's file is silently destroyed (data loss).
5. Content-bleed variant (forge2652b.img: fileA's DATA brefs CHECK_NONE, as on a no-check hammer2 fs): remounting and reading fileA chunks 16..19 returns FILEB-CHUNK-000000..000003 — fileA serves another file's bytes:

=== fileA chunks 16..19 after remount (cross-file bleed?):
FILEB-CHUNK-000000
FILEB-CHUNK-000001
FILEB-CHUNK-000002
FILEB-CHUNK-000003

Fix validation (kernel #1 with hunk 3 of fix_all_three_findings.diff)

start = ((int)(data_off >> BLOCK_RADIX) & (HAMMER2_BMAP_BLOCKS_PER_ELEMENT - 1)) * 2

No panic in either run (this bug is silent corruption, not a crash).

Threat model

Unprivileged multi-user system: user B's writes (after any crash-recovery mismark of user A's blocks, or a dedup-adjust on an affected offset) are allocated on top of user A's live data → destruction/disclosure of A's file content; no mount privilege required for the crash-recovery trigger. Crafted-image mount makes it fully deterministic (this PoC).

Artifacts

• forge_2652.py (pair-clear + mtid-bump forge), forge2652.img.gz, forge2652b.img.gz (CHECK_NONE-bref bleed variant, see build.sh), after2652.img.gz (post-corruption image), fileA.bin.gz/fileB.bin.gz.
• run.log — full session (corruption + EIO + bleed).
• fix.diff — the & 31 fix; shared validation kernel log in DF-2651's fix_all_three_findings.diff / fix_build.log / fix_run.log.