Summary

hammer_indirect_callback() validates that the device-side buffer covers the request only via KKASSERT(bp->b_bufsize >= obp->b_bufsize) — compiled out on production kernels — and then bcopy()s obp->b_bufsize bytes out of bp->b_data; the preceding CRC check has the same unguarded assumption. The code's own comment admits fragility ('due to big-block recycling and other factors there is some fragility there'), and HAMMER genuinely mixes 16K and 64K buffer sizes in the large-data zone, so a future regression in buffer sizing turns this into an OOB kernel heap read copied into a user-readable file buffer. Currently not exploitable: getblk guarantees an exact size match (disposes of mismatched buffers and retries), both breadcb and cluster_readcb acquire the callback's buffer at exactly obp->b_bufsize, and the path requires hammer_double_buffer=1 (non-default). Filed as Info hardening: the memory-safety property is incidental (relies on distant getblk internals) and any buffer-size regression immediately becomes an OOB read (kernel heap → user file page) on production kernels. Fix: convert the assert into an explicit runtime check + short-circuit the CRC condition (row diff). Same assert-as-bounds-check class as DF-3003 (:931), kept separate because the guarded operations differ.

Timeline

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