hammer2 ZLIB decompression failure returns zero-filled SUCCESS (b_error never set) — silent data substitution on malformed compressed blocks

Summary

hammer2_decompress_ZLIB_callback (strategy.c:258-265): when inflate(..., Z_FINISH) returns anything other than Z_STREAM_END, the handler kprintf's "Fatal error during decompression", bzero's the scratch buffer, then unconditionally bcopy's it into bp->b_data, sets bp->b_resid = 0, and returns without setting b_error — the bio completes successfully and read(2) returns fabricated zeros for the block instead of EIO. (Check the LZ4 sibling callback for the same pattern.)

Root cause

Error return of the decompressor is not propagated into bp->b_error; the zero-fill-on-error is treated as a substitute result rather than a failure.

Threat model & preconditions

A hammer2 block that is checksum-VALID but zlib-malformed (crafted image — attacker authors garbage with a recomputed check, CHECK_NONE ancestors make this trivial with the DF-2616..2654 forging family; or a compressed block written by a buggy/foreign implementation). Any read of the file silently substitutes zeros: backup/verification tooling that trusts read(2) integrity sees success with corrupted data. No memory corruption; pure integrity failure. Not reachable via ordinary bit-rot on default check methods (the checksum fails first → EIO).

Recommended fix

On decompression failure set bp->b_error = EIO; bp->b_flags |= B_ERROR; (and skip the bcopy) so the read fails loudly; same for the LZ4 callback if it shares the pattern.

References

• findings/poc/DF-2656 (the zlib batch audit that surfaced this)
• DF-2633/DF-2642 (the sibling swallowed-error family)

Timeline

• 2026-08-29 Surfaced during the pass-2 zlib batch audit (GLM 5.3); line-verified by the orchestrator (strategy.c:258-272).