AIKIDO-2026-643290

TL;DR

Before the fix, into_padded_blocks accepted an output buffer only as long as the input and still built a padded buffer containing a padding tail block; when the caller then used get_tail_block or into_out, the crate wrote or read one block past the output allocation. Any crate consumer calling this public API with the optional block-padding feature enabled and an output buffer without room for the padding tail hit the out-of-bounds access. The missing check existed only in 0.2.3; earlier releases rejected undersized output buffers with PadError. The fix counts the output buffer's full blocks and returns PadError before building the padded buffer when the output cannot hold the padded data.