crypto: chcr - Free fallback transforms when device assignment fails
Subsystems (3)
PATCH 1/1 crypto: chcr - Free fallback transforms when device assignment fails
The skcipher, RFC3686 and AEAD initialization callbacks allocate their fallback transforms before calling chcr_device_init(). If no active device can be assigned, chcr_device_init() returns -ENXIO and the fallback is leaked. The crypto core does not invoke the algorithm's exit callback after its initialization callback fails.
Free the fallback transform before returning the device assignment error in each of these initialization callbacks.
--- drivers/crypto/chelsio/chcr_algo.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
drivers/crypto/chelsio/chcr_algo.c +18 -3
@@ -1439,6 +1439,7 @@ static int chcr_init_tfm(struct crypto_skcipher *tfm)struct skcipher_alg *alg =crypto_skcipher_alg (tfm);struct chcr_context *ctx =crypto_skcipher_ctx (tfm);struct ablk_ctx *ablkctx =ABLK_CTX (ctx); +int ret; ablkctx->sw_cipher =crypto_alloc_skcipher (alg->base.cra_name,0 ,CRYPTO_ALG_NEED_FALLBACK );
@@ -1450,7 +1451,11 @@ static int chcr_init_tfm(struct crypto_skcipher *tfm)crypto_skcipher_set_reqsize (tfm,sizeof (struct chcr_skcipher_req_ctx ) +crypto_skcipher_reqsize (ablkctx->sw_cipher)); -return chcr_device_init (ctx); + ret =chcr_device_init (ctx); +if (ret) +crypto_free_skcipher (ablkctx->sw_cipher); + +return ret; }static int chcr_rfc3686_init (struct crypto_skcipher *tfm)
@@ -1458,6 +1463,7 @@ static int chcr_rfc3686_init(struct crypto_skcipher *tfm)struct skcipher_alg *alg =crypto_skcipher_alg (tfm);struct chcr_context *ctx =crypto_skcipher_ctx (tfm);struct ablk_ctx *ablkctx =ABLK_CTX (ctx); +int ret;/*RFC3686 initialises IV counter value to 1, rfc3686(ctr(aes)) * cannot be used as fallback in chcr_handle_cipher_response
@@ -1470,7 +1476,11 @@ static int chcr_rfc3686_init(struct crypto_skcipher *tfm) }crypto_skcipher_set_reqsize (tfm,sizeof (struct chcr_skcipher_req_ctx ) +crypto_skcipher_reqsize (ablkctx->sw_cipher)); -return chcr_device_init (ctx); + ret =chcr_device_init (ctx); +if (ret) +crypto_free_skcipher (ablkctx->sw_cipher); + +return ret; }
@@ -3164,6 +3174,7 @@ static int chcr_aead_cra_init(struct crypto_aead *tfm) {struct chcr_aead_ctx *aeadctx =AEAD_CTX (a_ctx (tfm));struct aead_alg *alg =crypto_aead_alg (tfm); +int ret; aeadctx->sw_cipher = crypto_alloc_aead(alg->base.cra_name, 0, CRYPTO_ALG_NEED_FALLBACK |
@@ -3174,7 +3185,11 @@ static int chcr_aead_cra_init(struct crypto_aead *tfm) tfm,max (sizeof (struct chcr_aead_reqctx ),sizeof (struct aead_request ) + crypto_aead_reqsize(aeadctx->sw_cipher))); -return chcr_device_init (a_ctx (tfm)); + ret =chcr_device_init (a_ctx (tfm)); +if (ret) +crypto_free_aead (aeadctx->sw_cipher); + +return ret; }static void chcr_aead_cra_exit (struct crypto_aead *tfm)
Signature · 1 line
2.34.1
Quoted 9 lines · Wentao Liang
The skcipher, RFC3686 and AEAD initialization callbacks allocate their fallback transforms before calling
chcr_device_init(). If no active device can be assigned,chcr_device_init()returns-ENXIOand the fallback is leaked. The crypto core does not invoke the algorithm's exit callback after its initialization callback fails.Free the fallback transform before returning the device assignment error in each of these initialization callbacks.
Quoted 9 lines
Fixes b8fd1f4170e7 ("crypto: chcr - Add ctr mode and process large sg entries for cipher")Fixes 0e93708dabc0 ("crypto: chcr - Add fallback for AEAD algos")Assisted-by DeepSeek-V4.1-Flash and OpenAI CodexSigned-off-by Wentao Liang <[email protected]>--- drivers/crypto/chelsio/chcr_algo.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
Multiple things here:
1. Your team ignored completely previous feedback. Multiple times.
2. You use multiple identities with this email, thus I doubt that we speak with an actual person.
3. Your bot does not even bother running checkpatch, right?
4. Nothing of this was reproduced nor tested.
5. Finally, the same feedback:
You sent multiple independent patches, to multiple independent subsystems. The amount of these patches clearly suggest this was AI generated and most likely not tested.
More importantly, you sent all this work without properly organizing relevant patches into patchsets. This makes reviewing difficult and might cause multiple reviewers to address the same issue. Replying to the entire set is impossible and requires handling each patch independently, instead of applying or discarding the set. Maintainers also won't see the bigger picture of your work. Quite worrying.
This is on the verge of hostile patch: bomb us with so many contributions, we won't be able to handle them in efficient manner, like responding ONCE to ask you to slow down. Considering all this is untested and LLM generated, I have even more doubts whether this should be considered for review.
Please read kernel documentation BEFORE posting more work. It will explain you how to identify subsystems, how to organize your work per subsystem (so a patchset grouping multiple patches with a short cover letter), how to document usage of LLM and what you should not do if this was posted in a good faith.
Best regards,
Krzysztof