Replace memcmp() with crypto_memneq() for cryptographic digest and
signature comparisons to prevent timing side-channel attacks.

crypto/rsassa-pkcs1.c: RSA signature digest verification used memcmp
which can leak valid prefix length via timing analysis, user data
could reach the leaky comparison via the digest argument to verify.

Assisted-by: gregkh_clanker_t1000
Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com>
---
 crypto/rsassa-pkcs1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/rsassa-pkcs1.c b/crypto/rsassa-pkcs1.c
index 94fa5e9600e7..a612a9eef2dd 100644
--- a/crypto/rsassa-pkcs1.c
+++ b/crypto/rsassa-pkcs1.c
@@ -291,7 +291,7 @@ static int rsassa_pkcs1_verify(struct crypto_sig *tfm,
 	/* RFC 8017 sec 8.2.2 step 4 - comparison of digest with out_buf */
 	if (dlen != dst_len - pos)
 		return -EKEYREJECTED;
-	if (memcmp(digest, out_buf + pos, dlen) != 0)
+	if (crypto_memneq(digest, out_buf + pos, dlen))
 		return -EKEYREJECTED;
 
 	return 0;
-- 
2.43.0

On Fri, Jul 10, 2026 at 07:29:33PM +0200, David C.C.M. Gall wrote:
> Replace memcmp() with crypto_memneq() for cryptographic digest and
> signature comparisons to prevent timing side-channel attacks.
> 
> crypto/rsassa-pkcs1.c: RSA signature digest verification used memcmp
> which can leak valid prefix length via timing analysis, user data
> could reach the leaky comparison via the digest argument to verify.
> 
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com>

While we should use crypto_memneq() on MACs, auth tags, and other secret
data, I don't think we should let it creep into domains where it is
clearly not needed, like public key signature verification.

- Eric

On Fri, Jul 10, 2026 at 05:37:18PM -0400, Eric Biggers wrote:
> On Fri, Jul 10, 2026 at 07:29:33PM +0200, David C.C.M. Gall wrote:
> > Replace memcmp() with crypto_memneq() for cryptographic digest and
> > signature comparisons to prevent timing side-channel attacks.
> > 
> > crypto/rsassa-pkcs1.c: RSA signature digest verification used memcmp
> > which can leak valid prefix length via timing analysis, user data
> > could reach the leaky comparison via the digest argument to verify.
> > 
> > Assisted-by: gregkh_clanker_t1000
> > Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com>
> 
> While we should use crypto_memneq() on MACs, auth tags, and other secret
> data, I don't think we should let it creep into domains where it is
> clearly not needed, like public key signature verification.

But isn't this user-controlled data and so a user could use it to figure
out the key?

thanks,

greg k-h

On Sat, Jul 11, 2026 at 6:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jul 10, 2026 at 05:37:18PM -0400, Eric Biggers wrote:
> > On Fri, Jul 10, 2026 at 07:29:33PM +0200, David C.C.M. Gall wrote:
> > > Replace memcmp() with crypto_memneq() for cryptographic digest and
> > > signature comparisons to prevent timing side-channel attacks.
> > >
> > > crypto/rsassa-pkcs1.c: RSA signature digest verification used memcmp
> > > which can leak valid prefix length via timing analysis, user data
> > > could reach the leaky comparison via the digest argument to verify.
> > >
> > > Assisted-by: gregkh_clanker_t1000
> > > Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com>
> >
> > While we should use crypto_memneq() on MACs, auth tags, and other secret
> > data, I don't think we should let it creep into domains where it is
> > clearly not needed, like public key signature verification.
>
> But isn't this user-controlled data and so a user could use it to figure
> out the key?

This is signature verification with a public key. So the user knows
the key already.

> thanks,
>
> greg k-h
>

Ignat

On Sat, Jul 11, 2026 at 09:00:23AM +0100, Ignat Korchagin wrote:
> On Sat, Jul 11, 2026 at 6:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Jul 10, 2026 at 05:37:18PM -0400, Eric Biggers wrote:
> > > On Fri, Jul 10, 2026 at 07:29:33PM +0200, David C.C.M. Gall wrote:
> > > > Replace memcmp() with crypto_memneq() for cryptographic digest and
> > > > signature comparisons to prevent timing side-channel attacks.
> > > >
> > > > crypto/rsassa-pkcs1.c: RSA signature digest verification used memcmp
> > > > which can leak valid prefix length via timing analysis, user data
> > > > could reach the leaky comparison via the digest argument to verify.
> > > >
> > > > Assisted-by: gregkh_clanker_t1000
> > > > Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com>
> > >
> > > While we should use crypto_memneq() on MACs, auth tags, and other secret
> > > data, I don't think we should let it creep into domains where it is
> > > clearly not needed, like public key signature verification.
> >
> > But isn't this user-controlled data and so a user could use it to figure
> > out the key?
> 
> This is signature verification with a public key. So the user knows
> the key already.
> 
> > thanks,
> >
> > greg k-h
> >
> 
> Ignat
Nevermind, my reasoning on how this method is used was faulty. The
crypto_memneq call does not protect against digest forgery, the
public key is already available to anyone attempting verification,
so an attacker can compute the padding/digest offline without needing
the kernel's comparison at all, timing or otherwise.

That said, this function already uses crypto_memneq for the hash-prefix
check a few lines above. I'd argue for consistency it's worth using it
for the digest comparison too.

David

On Sat, Jul 11, 2026 at 01:23:36PM +0200, David Gall wrote:
> That said, this function [rsassa_pkcs1_verify()] already uses
> crypto_memneq() for the hash-prefix check a few lines above.
> I'd argue for consistency it's worth using it for the digest
> comparison too.

I'd prefer the other way round, i.e. to use memcmp() for the hash_prefix
comparison.

Thanks,

Lukas