CCM builds on AES-CTR for encryption, and the crypto engine stalls on a partial final block just as it does for plain ctr(aes): a payload whose length is not a multiple of the AES block size leaves the operation incomplete and fails with a hardware operation error. This was caught by the ccm(aes) crypto self-tests. Force the software fallback for CCM requests whose message length is not block aligned, reusing the driver's existing need_fallback mechanism. Cc: stable@vger.kernel.org Fixes: 9363efb4181c ("crypto: qce - Add support for AEAD algorithms") Tested-by: Kuldeep Singh Tested-by: Pankaj Patil Signed-off-by: Bartosz Golaszewski --- drivers/crypto/qce/aead.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/crypto/qce/aead.c b/drivers/crypto/qce/aead.c index b7873852249dffeb91d09df3bae6534f77c08b7e..19d7e92aaeda0df1072114fa0435dc40e1eb6849 100644 --- a/drivers/crypto/qce/aead.c +++ b/drivers/crypto/qce/aead.c @@ -515,6 +515,14 @@ static int qce_aead_crypt(struct aead_request *req, int encrypt) fallback = true; } + /* + * CCM uses AES-CTR internally and the CE stalls on a partial final + * block, so a payload that is not a multiple of the block size has to + * be handled by the fallback. + */ + if (IS_CCM(rctx->flags) && !IS_ALIGNED(rctx->cryptlen, AES_BLOCK_SIZE)) + fallback = true; + /* If fallback is needed, schedule and exit */ if (fallback) { aead_request_set_tfm(&rctx->fallback_req, ctx->fallback); -- 2.47.3