On Mon, Jan 30, 2023 at 11:42:41AM +0100, Ard Biesheuvel wrote: > > > diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c > > index c4f14415f5f0..25cd3808ecbe 100644 > > --- a/arch/arm64/crypto/aes-ce-ccm-glue.c > > +++ b/arch/arm64/crypto/aes-ce-ccm-glue.c > > @@ -161,43 +161,39 @@ static int ccm_encrypt(struct aead_request *req) > > memcpy(buf, req->iv, AES_BLOCK_SIZE); > > > > err = skcipher_walk_aead_encrypt(&walk, req, false); > > - if (unlikely(err)) > > - return err; > > > > Should we keep this? No point in carrying on, and calling > ce_aes_ccm_final() and scatterwalk_map_and_copy() in this state is > best avoided. First of all I don't think there is any risk of information leaks in this case. We're simply hashing the associated data by itself as if the message was zero-length. So it's a question of doing unnecessary work on the error-path. The Linux way is to optimise for the common case so adding a short-circuit solely to improve the error case would seems to be unnecessary. For context the errors that we're expecting at this point are memory allocation failures, not anything untoward in the input data. Thanks, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
