DF-2658 — hammer2_sync_replace() no-op resize: kernel OOB read persisted

to cluster media (cross-file disclosure + kernel-memory bytes) / silent

truncation / NULL-source bcopy for embedded dirents

sys/vfs/hammer2/hammer2_synchro.c:939-945 (resize no-op) and :1041/:1049 (unbounded bcopy). Medium / hammer2 / CWE-125.

VERIFIED (reproduced) on the stock INVARIANTS guest — see VERDICT.md.

What it is

The resize branch in hammer2_sync_replace() computes nradix = hammer2_getradix(chain->bytes) — the OLD size — so hammer2_chain_resize() early-returns (chain.c:1363-1366) and the chain keeps its old allocation size; the subsequent bcopy(data, chain->data, chain->bytes) copies chain->bytes out of the focus's focus->bytes-sized buffer:

• focus smaller -> OOB read past the focus's logical allocation: rest of the 64KB dio media region (other files' block content) plus bytes past the end of the 64KB kernel dio buffer (kernel memory), CRC'd and flushed into the synced chain (info leak persisted to media).
• focus larger -> silent truncation + inconsistent vradix metadata.
• embedded focus (DIRENT, bytes==0) -> bcopy(NULL, chain->data, 1024) panic (code-proven variant).

Reproduce

# guest (root):
/root/poc/df2658/build.sh-equivalent:  cc -O2 -o scanbin scanbin.c
sh trigger_df2658.sh          # ~3 min; everything lands in /root/poc/df2658/

Expected (stock kernel): the run log shows DATA_REPLACE_SEEN ... poll=N, and F_block_on_C.bin decomposes as [1024B focus content][d2's 4096B file content][B-media-matching zeros] [4096B of kernel memory past the dio buffer end — an ELF64 header is visible in this run]; ls -l F collapses 65536 -> 1024.

Fix

fix.diff — resize to the focus's radix (rounded up for non-pow2 compressed sizes), bound both copies by min(focus->bytes, chain->bytes) with the remainder zeroed, and bzero for the embedded-focus dirent transition. Validated on a rebuilt kernel (see VERDICT.md "Fix validation").

DF-2658 VERDICT — REPRODUCED (kernel OOB read persisted to cluster media)

Bottom line

On a stock DragonFly 6.5-DEVELOPMENT X86_64_GENERIC (INVARIANTS) kernel, a 3-master hammer2 cluster (same-pfs_clid dd clones, merged via EBUSY mounts) whose columns A/B (quorum-agreeing) hold a file F with a 1024-byte data-chain allocation while the diverged column C holds the same key (same dirent name, same inum, same lbase-0 data-chain key) with a 65536-byte allocation, drives C's sync thread into hammer2_sync_replace() where:

• sys/vfs/hammer2/hammer2_synchro.c:939-945 — the resize branch computes nradix = hammer2_getradix(chain->bytes) (the OLD size), so hammer2_chain_resize() sees nbytes == obytes and early-returns a guaranteed no-op (hammer2_chain.c:1363-1366), and
• sys/vfs/hammer2/hammer2_synchro.c:1041 — bcopy(data, chain->data, chain->bytes) copies 65536 bytes out of the focus's 1024-byte allocation (data = hammer2_xop_gdata(xop) = focus->data, a pointer into a HAMMER2_PBUFSIZE (64KB) dio buffer, hammer2_io.c:113).

The overwritten 64KB chain data is then CRC'd by hammer2_chain_setcheck() and flushed to C's media. Decoded on-media evidence (F_block_on_C.bin):

The OFF_B % 65536 = 4096 geometry is the smoking gun: the copy starts 4096 bytes into a 65536-byte kernel buffer with length 65536, so it runs exactly 4096 bytes past the buffer end — and those 4096 bytes (3423 nonzero, ELF-header-led) are on C's disk inside F's block, having never been written by anyone.

Also observed: F's logical size collapses 65536 -> 1024 (the focus inode wins) — the "silent truncation" half of the finding.

Guest: DragonFly 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 2026, X86_64_GENERIC (INVARIANTS), QEMU/KVM, stock kernel.

Reproduction (trigger_df2658.sh, run.log)

1. newfs_hammer2 -L tv58 on a 256MB image; clone.
2. Column A (solo rw): create d1(4KB), F(1KB), d2(4KB) in this order; unmount; B = dd(A) (bit-identical -> A/B form the 2-of-3 quorum).
3. Column C (solo rw): same creation order (same inums/dirent keys/data-chain key), but F is written in two stages — 1 byte, sync, then the full 64KB — which shifts F's inode-chain and data-chain modify_tids past A/B's without changing the inum order (run-2 lesson: identical single-shot sequences on cloned allocators make every mtid equal and the scan is skipped as "100% match").
4. Mount A rw; merge B and C (EBUSY mounts). vfs.hammer2.debug=1 traces: replace rec ... slave 2 3.0000000000000000 mod=0x13 — the size-diverged DATA chain "replace" on column 2 (C) = the bug executing (synchro.c:1041 bcopy ran with chain->bytes=65536, focus->bytes=1024).
5. sync fired the moment the replace appeared (dmesg poll, DATA_REPLACE_SEEN poll=1); F's poisoned block was flushed and extracted from C.img with scanbin (see run.log; artifacts F_block_on_C.bin etc.).

Precondition reality check (reachability)

The size-mismatched same-key state arises whenever a column's data-chain allocation differs from the quorum's: forged/mismatched cluster images, or naturally diverged columns after partial write failures / offline writes. The rig manufactures it with unprivileged-equivalent file writes (a solo mount is required for the divergence step — i.e. an operator action or a forged image, matching the filed PR:H / "forged or naturally diverged cluster images" threat model). Remote forging of the same state over the dmsg cluster protocol is not needed for the primitive itself: the bug is in the local sync thread's copy loop.

Related crash observed during verification (NOT this finding)

Within seconds after any successful catch-up pass on the stock kernel, the guest panics at hammer2_inode_chain_and_parent.cold.9+0x15 (hammer2_inode.c:446-453: chain == NULL -> chain->parent, fault va 0x118) via hammer2_chain_inode_find() (hammer2_chain.c:5678), reached from xop unlink/lookup paths (hammer2_xops.c:96/298/472) racing the sync thread's partially-populated in-core inodes. This is a separate pre-existing defect (same family as DF-2620/DF-2657's multi-chain lifecycle bugs); it cut every verification run short after the DF-2658 primitive executed and was raced successfully by the DATA_REPLACE_SEEN + immediate sync poll. Full backtraces in panic3.backtrace.txt (and attempts_fghi.console.txt in the DF-2660 pack).

Fix validation

fix.diff (authored after reproduction, applied inside the guest's /usr/src copy only; never to the audit tree): 1. resize branch uses hammer2_getradix(focus->bytes), rounded up to hold non-power-of-2 (compressed) foci; 2. the DATA/DIRENT copies are bounded by min(focus->bytes, chain->bytes) with the remainder zeroed; 3. an embedded focus (bytes == 0) into a non-embedded local dirent clears the local allocation instead of bcopy(NULL, ...) (the panic variant).

(Validation run results appended below after the rebuilt kernel.)

Fix validation (kernel #1, Thu Oct 15 07:30:39 UTC 2026, both fixes applied)

Build: cd /usr/src && make nativekernel && make installkernel on the guest with fix2658.diff + fix2660.diff applied (fix_build.log, 17087 lines, BUILD_INSTALL_DONE_RC0; hammer2_synchro.c compiled clean under -Werror).

Baseline (stock kernel #0, same images/flow): F_block_on_C.bin = [1024B f_ab][4096B d2 file content][zeros matching B media for exactly 60416 bytes][4096B kernel memory past the dio buffer end (3423 nonzero, ELF64 header visible)] <- THE BUG

Patched (kernel #1, identical trigger): * the catch-up pass runs to completion through the patched path (run_fixed.log / serial: replace rec ... 3.0000000000000000 mod=0x13, deferred finals 0x15/0x11, root final 0x19); * f_ab content found on C.img at 3 offsets (findfix_C_fab.txt: 29372416, 29425664, 29491200) and none carries the stock signature: tail-vs-B-media comparison gives equal_prefix=0 for every candidate (stock: 60416), no d2 content adjacent at +1024, no kernel-byte window; F's data chain is a 1024-byte allocation holding exactly f_ab; * the original 64KB C allocation is gone/reclaimed (findfix_C_fc.txt: 0 hits for the old f_c content) and F's logical size follows the focus (1024) with consistent vradix metadata.

=> the persisted OOB read is GONE on the patched kernel; fix_status=fixed (baseline_reproduced=1, patched_reproduced=0).

Note: the pre-existing sibling NULL-deref (hammer2_inode_chain_and_parent, fault 0x118, via hammer2_chain_inode_find) still terminates the session a few seconds after the pass on the patched kernel — unchanged by this fix, out of scope, captured in panic_fixed_kernel_siblingcrash.txt. It did not affect the extraction (the trigger's DATA_REPLACE_SEEN poll syncs and the images persist on disk across the crash+reboot).

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.