[PATCH v3] crypto: rsassa-pkcs1 - Align DMA buffer to CRYPTO_DMA_ALIGN

[PATCH v3] crypto: rsassa-pkcs1 - Align DMA buffer to CRYPTO_DMA_ALIGN

[Changwei Zou]

out_buf is used as a DMA buffer for the RSA verification operation.
If out_buf is not aligned to CRYPTO_DMA_ALIGN, cacheline sharing
problems (data corruption) would occur on CPUs with DMA-incoherent caches,
leading to -EKEYREJECTED.

Fix by aligning out_buf to CRYPTO_DMA_ALIGN using PTR_ALIGN(), and
allocating CRYPTO_DMA_ALIGN - 1 extra bytes in the child_req allocation
to accommodate the alignment padding as child_reqsize is a variable.

The intermittent error 'Key was rejected by service' on i.MX8 with CAAM
can be triggered when loading signed kernel modules.

    for i in $(seq 1 100); do
        sudo modprobe xfs 2>&1 && echo "SUCCESS on attempt $i" \
        && sudo rmmod xfs || echo "FAILED on attempt $i"
    done

Fixes: 8552cb04e083 ("crypto: rsassa-pkcs1 - Copy source data for SG list")
Signed-off-by: Changwei Zou <changwei.zou@canonical.com>
---
 crypto/rsassa-pkcs1.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/crypto/rsassa-pkcs1.c b/crypto/rsassa-pkcs1.c
index 94fa5e9600e7..c683f3c61528 100644
--- a/crypto/rsassa-pkcs1.c
+++ b/crypto/rsassa-pkcs1.c
@@ -237,12 +237,13 @@ static int rsassa_pkcs1_verify(struct crypto_sig *tfm,
 		return -EINVAL;
 
 	/* RFC 8017 sec 8.2.2 step 2 - RSA verification */
-	child_req = kmalloc(sizeof(*child_req) + child_reqsize + ctx->key_size,
-			    GFP_KERNEL);
+	child_req = kmalloc(sizeof(*child_req) + child_reqsize +
+			    ctx->key_size + CRYPTO_DMA_ALIGN - 1, GFP_KERNEL);
 	if (!child_req)
 		return -ENOMEM;
 
-	out_buf = (u8 *)(child_req + 1) + child_reqsize;
+	out_buf = PTR_ALIGN((u8 *)(child_req + 1) + child_reqsize,
+			    CRYPTO_DMA_ALIGN);
 	memcpy(out_buf, src, slen);
 
 	crypto_init_wait(&cwait);
-- 
2.43.0

Re: [PATCH v3] crypto: rsassa-pkcs1 - Align DMA buffer to CRYPTO_DMA_ALIGN

[Lukas Wunner]

On Wed, Jul 29, 2026 at 10:41:56AM +1000, Changwei Zou wrote:
> +++ b/crypto/rsassa-pkcs1.c
> @@ -237,12 +237,13 @@ static int rsassa_pkcs1_verify(struct crypto_sig *tfm,
>  		return -EINVAL;
>  
>  	/* RFC 8017 sec 8.2.2 step 2 - RSA verification */
> -	child_req = kmalloc(sizeof(*child_req) + child_reqsize + ctx->key_size,
> -			    GFP_KERNEL);
> +	child_req = kmalloc(sizeof(*child_req) + child_reqsize +
> +			    ctx->key_size + CRYPTO_DMA_ALIGN - 1, GFP_KERNEL);
>  	if (!child_req)
>  		return -ENOMEM;
>  
> -	out_buf = (u8 *)(child_req + 1) + child_reqsize;
> +	out_buf = PTR_ALIGN((u8 *)(child_req + 1) + child_reqsize,
> +			    CRYPTO_DMA_ALIGN);
>  	memcpy(out_buf, src, slen);
>  
>  	crypto_init_wait(&cwait);

Thank, this all looks good to me.

However after reading around a bit in crypto code, I'm under the
impression that the "native" way of doing this is to have struct
caam_akcipher_alg[] in drivers/crypto/caam/caampkc.c define
".cra_alignmask = CRYPTO_DMA_ALIGN - 1," and then have
rsassa_pkcs1_verify() call crypto_akcipher_alignmask()
to determine the amount of padding needed and the alignment.

That crypto_akcipher_alignmask() doesn't exist yet, but can
easily be copy-pasted from crypto_skcipher_alignmask()
except it invokes crypto_akcipher_tfm() instead of
crypto_skcipher_tfm().

Finally the kernel-doc of struct crypto_alg would have to be
amended because the documentation of the cra_alignmask member
does not mention akcipher yet.

Now this may all sound like a roundabout way of doing things
but it seems to fit neatly into the existing OO-like approach
of the crypto subsystem and so I strongly suspect that's what
Herbert would want.  I apologize for not having steered you
in that direction right away, I feel like a novice myself
sometimes when navigating that code.

You can find some pre-existing use cases with
"git grep alignmask -- crypto/".  E.g. in crypto/xctr.c,
alignmask is determined with crypto_cipher_alignmask()
and that (plus 1) is then fed to PTR_ALIGN().

Basically the idea is that whether padding is added at all
and how much depends on the child request, and that child
request knows exactly whether it needs any padding at all.

I think you can do all of that in a single patch and thus
keep this easily backportable to stable kernels.

Thanks!

Lukas

Re: [PATCH v3] crypto: rsassa-pkcs1 - Align DMA buffer to CRYPTO_DMA_ALIGN

[Lukas Wunner]

On Wed, Jul 29, 2026 at 10:41:56AM +1000, Changwei Zou wrote:
> out_buf is used as a DMA buffer for the RSA verification operation.
> If out_buf is not aligned to CRYPTO_DMA_ALIGN, cacheline sharing
> problems (data corruption) would occur on CPUs with DMA-incoherent caches,
> leading to -EKEYREJECTED.
> 
> Fix by aligning out_buf to CRYPTO_DMA_ALIGN using PTR_ALIGN(), and
> allocating CRYPTO_DMA_ALIGN - 1 extra bytes in the child_req allocation
> to accommodate the alignment padding as child_reqsize is a variable.

sashiko believes that rsassa_pkcs1_sign() suffers from the same issue
as the _verify() code path:

https://sashiko.dev/#/patchset/20260729004156.11925-1-changwei.zou%40canonical.com

That doesn't seem to be the case right now because the only callers
in the tree (test_sig_one() and keyctl_pkey_e_d_s()) use kmalloc()
or kzalloc() for the destination buffer, which should fulfil the
alignment requirements of the caam hardware.

Thanks,

Lukas

Re: [PATCH v3] crypto: rsassa-pkcs1 - Align DMA buffer to CRYPTO_DMA_ALIGN

[Herbert Xu]

On Wed, Jul 29, 2026 at 09:26:09PM +0200, Lukas Wunner wrote:
>
> That crypto_akcipher_alignmask() doesn't exist yet, but can
> easily be copy-pasted from crypto_skcipher_alignmask()
> except it invokes crypto_akcipher_tfm() instead of
> crypto_skcipher_tfm().

I don't think we should create crypto_akcipher_alignmask.  In fact
alignmask is being phased out everywhere else too.

The general rule is for the driver to ensure that the data is
aligned, possibly by copying if necessary.

Even when alignmask is used it's still the driver's responsibility
to copy the data when it isn't aligned.

So the bug isn't really in rsa but it's the fault of the underlying
driver if it didn't check alignment before supplying the buffer
to the hardware.

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