Re: [BUG] crypto: caam - RSA encrypt doesn't always complete new data in out_buf

[Lukas Wunner <lukas@wunner.de>]

On Wed, Feb 25, 2026 at 08:47:07AM +0000, Kepplinger-Novakovic Martin wrote:
> Am Mittwoch, dem 25.02.2026 um 09:13 +0100 schrieb Lukas Wunner:
> > On Wed, Feb 25, 2026 at 08:02:08AM +0000, Kepplinger-Novakovic Martin wrote:
> > > ok I can confirm: "git checkout 2f1f34c1bf7b^" indeed is ok and
> > > 2f1f34c1bf7b is bad.
> > > 
> > > It's not the same behaviour I described (from v6.18/v6.19. that could be
> > > a combination of bugs) because on 2f1f34c1bf7b regdb cert verify succeeds,
> > > only dm-verity fails
> > 
> > Hm, I assume CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API=n magically
> > makes the issue go away?
> 
> correct. where I see that specific issue (on 2f1f34c1bf7b and v6.7)
> "caam_jr 2142000.jr: 40000013: DECO: desc idx 0: Header Error.
> Invalid length or parity, or certain other problems."
> it then goes away.
> 
> on v6.18 CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API=n doesn't seem to help
> and I see the bugreport's behaviour.

I note that for the RSA verification, since 8552cb04e083 the same buffer
in memory is used for source and destination of RSA encrypt operation
invoked by crypto/rsassa-pkcs1.c.

That's fine for the RSA software implementation in crypto/rsa.c but
I could very well imagine it causes problems with an RSA accelerator,
particularly because rsa_edesc_alloc() in drivers/crypto/caam/caampkc.c
now maps the same buffer with DMA_TO_DEVICE and then DMA_FROM_DEVICE.

On v6.19, 8552cb04e083 seems to revert cleanly.  Could you try that
and see if it helps?  Be sure to set CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API=n
and CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API=y so that we focus on the RSA
issue for now.  We can look at the ahash one afterwards.

Thanks,

Lukas