Replace memcmp() with crypto_memneq() when comparing message digests
during PKCS#7 signature verification.

memcmp() is not constant-time and returns early on the first byte
mismatch. This creates a timing side-channel that could allow an
attacker to forge valid signatures by measuring verification time
and recovering the expected digest value byte-by-byte.

crypto_memneq() performs a constant-time comparison, eliminating
the timing oracle.

This affects all users of PKCS#7 signature verification including:
 - Kernel module signature verification (CONFIG_MODULE_SIG)
 - Firmware signature verification
 - Kexec image signature verification
 - IMA appraisal

Fixes: 9f0d33146e2a ("PKCS#7: Digest the data in a signed-data message")
Signed-off-by: Daniel Hodges <hodgesd@meta.com>
---
 crypto/asymmetric_keys/pkcs7_verify.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
index 6d6475e3a9bf..c69cd240bd7e 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -4,20 +4,21 @@
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
  */
 
 #define pr_fmt(fmt) "PKCS7: "fmt
 #include <linux/kernel.h>
 #include <linux/export.h>
 #include <linux/slab.h>
 #include <linux/err.h>
 #include <linux/asn1.h>
+#include <crypto/utils.h>
 #include <crypto/hash.h>
 #include <crypto/hash_info.h>
 #include <crypto/public_key.h>
 #include "pkcs7_parser.h"
 
 /*
  * Digest the relevant parts of the PKCS#7 data
  */
 static int pkcs7_digest(struct pkcs7_message *pkcs7,
 			struct pkcs7_signed_info *sinfo)
@@ -78,22 +79,22 @@ static int pkcs7_digest(struct pkcs7_message *pkcs7,
 			goto error;
 		}
 
 		if (sinfo->msgdigest_len != sig->digest_size) {
 			pr_warn("Sig %u: Invalid digest size (%u)\n",
 				sinfo->index, sinfo->msgdigest_len);
 			ret = -EBADMSG;
 			goto error;
 		}
 
-		if (memcmp(sig->digest, sinfo->msgdigest,
-			   sinfo->msgdigest_len) != 0) {
+		if (crypto_memneq(sig->digest, sinfo->msgdigest,
+				  sinfo->msgdigest_len)) {
 			pr_warn("Sig %u: Message digest doesn't match\n",
 				sinfo->index);
 			ret = -EKEYREJECTED;
 			goto error;
 		}
 
 		/* We then calculate anew, using the authenticated attributes
 		 * as the contents of the digest instead.  Note that we need to
 		 * convert the attributes from a CONT.0 into a SET before we
 		 * hash it.
-- 
2.47.3

On Sat, Jan 31, 2026 at 07:55:03PM -0800, Daniel Hodges wrote:
> This creates a timing side-channel that could allow an
> attacker to forge valid signatures by measuring verification time
> and recovering the expected digest value byte-by-byte.

Good luck with that.  The memcmp just checks that the CMS object
includes the hash of the data as a signed attribute.  It's a consistency
check of two attacker-controlled values, which happens before the real
signature check.  You may be confusing it with a MAC comparison.

- Eric

On Sun, Feb 1, 2026 at 5:41 AM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Sat, Jan 31, 2026 at 07:55:03PM -0800, Daniel Hodges wrote:
> > This creates a timing side-channel that could allow an
> > attacker to forge valid signatures by measuring verification time
> > and recovering the expected digest value byte-by-byte.
>
> Good luck with that.  The memcmp just checks that the CMS object
> includes the hash of the data as a signed attribute.  It's a consistency
> check of two attacker-controlled values, which happens before the real
> signature check.  You may be confusing it with a MAC comparison.

On top of that the CMS object and the hash inside is "public", so even
if you have state-of-the-art quantum computer thing you can just take
the object and forge the signature "offline"

> - Eric

On Sun, Feb 01, 2026 at 11:55:26AM +0100, Ignat Korchagin wrote:
> On Sun, Feb 1, 2026 at 5:41 AM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Sat, Jan 31, 2026 at 07:55:03PM -0800, Daniel Hodges wrote:
> > > This creates a timing side-channel that could allow an
> > > attacker to forge valid signatures by measuring verification time
> > > and recovering the expected digest value byte-by-byte.
> >
> > Good luck with that.  The memcmp just checks that the CMS object
> > includes the hash of the data as a signed attribute.  It's a consistency
> > check of two attacker-controlled values, which happens before the real
> > signature check.  You may be confusing it with a MAC comparison.
> 
> On top of that the CMS object and the hash inside is "public", so even
> if you have state-of-the-art quantum computer thing you can just take
> the object and forge the signature "offline"
> 
> > - Eric

I just went through the code flow again and that makes sense, sorry
about that!