Re: [PATCH v2 4/8] crypto: acomp - Add API to get a compression algorithm's batch-size.

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] crypto: acomp: broken type check and async gate in crypto_acomp_batch_size()
--

commit a38b95e87019ff2c11b51ebf159a082ec340456f
Author: Kanchana P. Sridhar <kanchanapsridhar2026@gmail.com>

crypto: acomp - Add API to get a compression algorithm's batch-size.

This commit adds a batch_size member to struct acomp_alg and introduces
crypto_acomp_batch_size() so callers such as zswap can query the maximum
number of requests an acomp algorithm can process in a batch.

> diff --git a/crypto/acompress.c b/crypto/acompress.c
> index c55b0e8eff3d8..8e285cb7477e9 100644
> --- a/crypto/acompress.c
> +++ b/crypto/acompress.c
> @@ -326,6 +326,20 @@ int crypto_acomp_decompress(struct acomp_req *req)
>  }
>  EXPORT_SYMBOL_GPL(crypto_acomp_decompress);
>  
> +unsigned int crypto_acomp_batch_size(struct crypto_acomp *tfm)
> +{
> +	if (acomp_is_async(tfm) &&
> +		(crypto_comp_alg_common(tfm)->base.cra_flags & CRYPTO_ALG_TYPE_ACOMPRESS)) {
> +		struct acomp_alg *alg = crypto_acomp_alg(tfm);
> +
> +		if (alg && alg->batch_size > 1)
> +			return alg->batch_size;
> +	}

[Severity: Medium]
Does the cra_flags check in crypto_acomp_batch_size() distinguish
struct acomp_alg from struct scomp_alg as intended?

In include/linux/crypto.h, algorithm types are 4-bit values under
CRYPTO_ALG_TYPE_MASK rather than single-bit flags:

    #define CRYPTO_ALG_TYPE_MASK		0x0000000f
    ...
    #define CRYPTO_ALG_TYPE_ACOMPRESS	0x0000000a
    #define CRYPTO_ALG_TYPE_SCOMPRESS	0x0000000b

Because (0x0b & 0x0a) == 0x0a, testing cra_flags & CRYPTO_ALG_TYPE_ACOMPRESS
without masking by CRYPTO_ALG_TYPE_MASK evaluates to true for both
CRYPTO_ALG_TYPE_ACOMPRESS and CRYPTO_ALG_TYPE_SCOMPRESS.

A struct crypto_acomp *tfm allocated via crypto_alloc_acomp() can wrap either
a struct acomp_alg or a struct scomp_alg. If an scomp_alg has CRYPTO_ALG_ASYNC
set in cra_flags (or if the acomp_is_async(tfm) check is removed), calling
crypto_acomp_alg(tfm) performs container_of() to struct acomp_alg on a
struct scomp_alg and reads alg->batch_size from unrelated memory inside
struct scomp_alg::streams.

Elsewhere in crypto/acompress.c, such as in crypto_acomp_init_tfm():

    if (tfm->__crt_alg->cra_type != &crypto_acomp_type)
        return crypto_init_scomp_ops_async(tfm);

the code checks cra_type == &crypto_acomp_type (or masks cra_flags with
CRYPTO_ALG_TYPE_MASK before comparing against CRYPTO_ALG_TYPE_ACOMPRESS) to
verify that the tfm is backed by a struct acomp_alg.

Also, should crypto_acomp_batch_size() gate on acomp_is_async(tfm)? A
synchronous struct acomp_alg registered via crypto_register_acomp() does not
set CRYPTO_ALG_ASYNC, which causes crypto_acomp_batch_size() to always return 1
even when batch_size > 1, whereas segmented request handling in
crypto_acomp_compress() and acomp_do_req_chain() checks
crypto_acomp_req_seg(tfm) (CRYPTO_ALG_REQ_SEG) instead.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261028030503.17923-1-kanchanapsridhar2026@gmail.com?part=4