On Wed, Mar 25, 2026 at 04:31:38PM +0100, Mikulas Patocka wrote:
> Hi Herbert
> 
> I am developing a new device mapper target that compresses data and I 
> found a bug in crypto/deflate.c that it sometimes returns -ENOSPC even if 
> the decompressed data fits into the destination buffer. I'm submitting 
> this patch to fix it.
> 
> Mikulas
> 
> 
> From: Mikulas Patocka <[email protected]>
> 
> The code in deflate_decompress_one may erroneously return -ENOSPC even if
> it didn't run out of output space. The error happens under this
> condition:
> 
> - Suppose that there are two input pages, the compressed data fits into
>   the first page and the zlib checksum is placed in the second page.
> 
> - The code iterates over the first page, decompresses the data and fully
>   fills the destination buffer, zlib_inflate returns Z_OK becuse zlib
>   hasn't seen the checksum yet.
> 
> - The outer do-while loop is iterated again, acomp_walk_next_src sets the
>   input parameters to the second page containing the checksum.
> 
> - We go into the inner do-while loop, execute "dcur =
>   acomp_walk_next_dst(&walk);". "dcur" is zero, so we break out of the
>   loop and return -ENOSPC, despite the fact that the decompressed data
>   fit into the destination buffer.
> 
> In order to fix this bug, this commit changes the logic when to report
> the -ENOSPC error. We report the error if the destination buffer is empty
> *and* if zlib_inflate didn't make any progress consuming the input
> buffer. If zlib_inflate consumes the trailing checksum, we see that it
> made progress and we will not return -ENOSPC.
> 
> Signed-off-by: Mikulas Patocka <[email protected]>
> 
> ---
>  crypto/deflate.c |   11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Reply via email to