[PATCH v2] crypto: deflate - fix decompression window size

[PATCH v2] crypto: deflate - fix decompression window size

[Giovanni Cabiddu]

deflate_decompress() initializes the inflate stream with windowBits set
to -DEFLATE_DEF_WINBITS (11 bits, 2KB window). Valid raw DEFLATE streams
allow window sizes up to MAX_WBITS (15 bits, 32KB).

Data compressed with a history window larger than 2 KB, for example
produced by hardware compressors such as QAT or IAA, might not be
decompressed by deflate-generic since the inflate stream is initialized
with a 2 KB window. This might be seen, for example, when
deflate-generic is used as fallback.

Use -MAX_WBITS when calling zlib_inflateInit2() to accept all valid raw
DEFLATE streams. The inflate workspace allocated in deflate_alloc_stream()
is already sized using zlib_inflate_workspacesize(), which accounts for
the maximum window size, so no allocation change is needed.

Fixes: f6ded09de8bd ("crypto: acomp - add support for deflate via scomp")
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Laurent M Coquerel <laurent.m.coquerel@intel.com>
---
Changes since v1:
- Updated commit message to clearly state why this is needed for the
  deflate algorithm (i.e. allow data produced by HW compressors with
  larger history windows to be decompressed by deflate-generic, which
  is used as fallback).
- Updated fixes tag to point to the commit that introduced deflate
  support in scomp.

 crypto/deflate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/deflate.c b/crypto/deflate.c
index 46fc7def8d4c..d347e506e6c3 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -203,7 +203,7 @@ static int deflate_decompress(struct acomp_req *req)
 	s = crypto_acomp_lock_stream_bh(&deflate_streams);
 	ds = s->ctx;
 
-	err = zlib_inflateInit2(&ds->stream, -DEFLATE_DEF_WINBITS);
+	err = zlib_inflateInit2(&ds->stream, -MAX_WBITS);
 	if (err != Z_OK) {
 		err = -EINVAL;
 		goto out;
-- 
2.53.0

Re: [PATCH v2] crypto: deflate - fix decompression window size

[Herbert Xu]

On Thu, Mar 26, 2026 at 09:59:22AM +0000, Giovanni Cabiddu wrote:
> deflate_decompress() initializes the inflate stream with windowBits set
> to -DEFLATE_DEF_WINBITS (11 bits, 2KB window). Valid raw DEFLATE streams
> allow window sizes up to MAX_WBITS (15 bits, 32KB).
> 
> Data compressed with a history window larger than 2 KB, for example
> produced by hardware compressors such as QAT or IAA, might not be
> decompressed by deflate-generic since the inflate stream is initialized
> with a 2 KB window. This might be seen, for example, when
> deflate-generic is used as fallback.
> 
> Use -MAX_WBITS when calling zlib_inflateInit2() to accept all valid raw
> DEFLATE streams. The inflate workspace allocated in deflate_alloc_stream()
> is already sized using zlib_inflate_workspacesize(), which accounts for
> the maximum window size, so no allocation change is needed.
> 
> Fixes: f6ded09de8bd ("crypto: acomp - add support for deflate via scomp")
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> Reviewed-by: Laurent M Coquerel <laurent.m.coquerel@intel.com>
> ---
> Changes since v1:
> - Updated commit message to clearly state why this is needed for the
>   deflate algorithm (i.e. allow data produced by HW compressors with
>   larger history windows to be decompressed by deflate-generic, which
>   is used as fallback).
> - Updated fixes tag to point to the commit that introduced deflate
>   support in scomp.
> 
>  crypto/deflate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

What happened to the parameters patch-set? Wouldn't this be something
that should be treated as a parameter?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: deflate - fix decompression window size

[Giovanni Cabiddu]

Hi Herbert,

On Fri, Apr 03, 2026 at 08:25:06AM +0800, Herbert Xu wrote:
> On Thu, Mar 26, 2026 at 09:59:22AM +0000, Giovanni Cabiddu wrote:
> > deflate_decompress() initializes the inflate stream with windowBits set
> > to -DEFLATE_DEF_WINBITS (11 bits, 2KB window). Valid raw DEFLATE streams
> > allow window sizes up to MAX_WBITS (15 bits, 32KB).
> > 
> > Data compressed with a history window larger than 2 KB, for example
> > produced by hardware compressors such as QAT or IAA, might not be
> > decompressed by deflate-generic since the inflate stream is initialized
> > with a 2 KB window. This might be seen, for example, when
> > deflate-generic is used as fallback.
> > 
> > Use -MAX_WBITS when calling zlib_inflateInit2() to accept all valid raw
> > DEFLATE streams. The inflate workspace allocated in deflate_alloc_stream()
> > is already sized using zlib_inflate_workspacesize(), which accounts for
> > the maximum window size, so no allocation change is needed.
> > 
> > Fixes: f6ded09de8bd ("crypto: acomp - add support for deflate via scomp")
> > Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> > Reviewed-by: Laurent M Coquerel <laurent.m.coquerel@intel.com>
> > ---
> > Changes since v1:
> > - Updated commit message to clearly state why this is needed for the
> >   deflate algorithm (i.e. allow data produced by HW compressors with
> >   larger history windows to be decompressed by deflate-generic, which
> >   is used as fallback).
> > - Updated fixes tag to point to the commit that introduced deflate
> >   support in scomp.
> > 
> >  crypto/deflate.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> What happened to the parameters patch-set?
I'm reworking the acomp/BTRFS set, and that will be included there.

> Wouldn't this be something that should be treated as a parameter?
I don't think this should be treated as a parameter. A decompressor must
be able to handle any valid DEFLATE stream. RFC1951 (section 3.3) [1]
states that while a compressor may restrict parameters such as window
size, a compliant decompressor must accept the full range defined by the
specification.

In this case, deflate-generic does not accept valid streams compressed
with the full 32KB history window, which is why I proposed this change.

[1] https://datatracker.ietf.org/doc/html/rfc1951

Regards,

-- 
Giovanni

Re: [PATCH v2] crypto: deflate - fix decompression window size

[Herbert Xu]

On Thu, Apr 16, 2026 at 06:03:59PM +0100, Giovanni Cabiddu wrote:
>
> I'm reworking the acomp/BTRFS set, and that will be included there.

I'd prefer a standalone parameters patch-set, with the first user
being zram.

> I don't think this should be treated as a parameter. A decompressor must
> be able to handle any valid DEFLATE stream. RFC1951 (section 3.3) [1]
> states that while a compressor may restrict parameters such as window
> size, a compliant decompressor must accept the full range defined by the
> specification.

I thought this is the whole point of parameters.  Different parameters
would generate compression output that may not be decompressed unless
you used the same set of parameters.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: deflate - fix decompression window size

[Giovanni Cabiddu]

Adding Sergey for zram.

On Mon, Apr 20, 2026 at 04:50:55PM +0800, Herbert Xu wrote:
> On Thu, Apr 16, 2026 at 06:03:59PM +0100, Giovanni Cabiddu wrote:
> >
> > I'm reworking the acomp/BTRFS set, and that will be included there.
> 
> I'd prefer a standalone parameters patch-set, with the first user
> being zram.
Sure, no problem.

I was already working in parallel on enabling zram to use acomp, so it
can leverage the compression accelerators. I'm also working on an
enhanced async version to better exploit the full parallelism of the
accelerators.
I have a preliminary patchset and can integrate the parameters work on
top of that.

One question on the design: my current implementation adds an
additional acomp‑based plugin to zcomp, allowing selection among all
implementations registered with acomp.
Do you think this is a reasonable initial approach, or were you instead
considering a full replacement of zcomp with acomp?

> 
> > I don't think this should be treated as a parameter. A decompressor must
> > be able to handle any valid DEFLATE stream. RFC1951 (section 3.3) [1]
> > states that while a compressor may restrict parameters such as window
> > size, a compliant decompressor must accept the full range defined by the
> > specification.
> 
> I thought this is the whole point of parameters.  Different parameters
> would generate compression output that may not be decompressed unless
> you used the same set of parameters.
Yes, I see your point, and I need to think this through some more.
Some hardware implementations may not allow configuring the window size.

I ran into this when falling back to deflate‑generic to decompress data
produced by one of the accelerators.

Thanks,

-- 
Giovanni

Re: [PATCH v2] crypto: deflate - fix decompression window size

[Herbert Xu]

On Mon, Apr 20, 2026 at 11:37:48AM +0100, Giovanni Cabiddu wrote:
>
> Yes, I see your point, and I need to think this through some more.
> Some hardware implementations may not allow configuring the window size.

That's fine.  It's just like hardware that can't handle all key
sizes for AES.  You just fallback to software if you encounter
parameters that the hardware does not support.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt