[PATCH 0/3] lib/crypto: Provide a function for zeroizing hmac_sha1_ctx

[PATCH 0/3] lib/crypto: Provide a function for zeroizing hmac_sha1_ctx

[Thomas Huth]

It's maybe not worth the effort for hmac_sha1_ctx right now (since there
is only one spot that forgot to zeroize the structure in case of errors),
but offering a function for zeroizing the data via __cleanup might help to
get future code into the proper shape right from the start. Thus let's
introduce a hmac_sha1_zeroize_ctx() function now and use it in the
appropriate spots.

Thomas Huth (3):
  crypto: Provide a wrapper for zeroizing hmac_sha1_ctx
  security: keys: trusted: always clear the hmac_sha1_ctx before
    returning
  lib/crypto: sha1: Use hmac_sha1_zeroize_ctx() instead of
    memzero_explicit()

 include/crypto/sha1.h                     | 17 +++++++++++++++++
 lib/crypto/sha1.c                         |  2 +-
 security/keys/trusted-keys/trusted_tpm1.c |  2 +-
 3 files changed, 19 insertions(+), 2 deletions(-)

-- 
2.55.0

[PATCH 1/3] crypto: Provide a wrapper for zeroizing hmac_sha1_ctx

[Thomas Huth]

From: Thomas Huth <thuth@redhat.com>

Some kernel code needs to zeroize their local hmac_sha1_ctx structures
after use to avoid leaking sensitive material on the stack.
Provide an hmac_sha1_zeroize_ctx() helper that can be used with __cleanup()
to automatically zeroize the context when it goes out of scope.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 include/crypto/sha1.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/include/crypto/sha1.h b/include/crypto/sha1.h
index 4d973e016cd69..888dfc62e1c65 100644
--- a/include/crypto/sha1.h
+++ b/include/crypto/sha1.h
@@ -7,6 +7,7 @@
 #define _CRYPTO_SHA1_H
 
 #include <linux/types.h>
+#include <linux/string.h>
 
 #define SHA1_DIGEST_SIZE        20
 #define SHA1_BLOCK_SIZE         64
@@ -106,6 +107,22 @@ struct hmac_sha1_ctx {
 	struct sha1_block_state ostate;
 };
 
+/**
+ * hmac_sha1_zeroize_ctx() - Zeroize a hmac_sha1_ctx structure
+ * @ctx: The location of the context that should be zeroized
+ *
+ * This function explicitly fills the hmac_sha1_ctx with zeroes. For
+ * example, it can be used with __cleanup() for local hmac_sha1_ctx
+ * structures on the stack, so that their content is not leaked via the
+ * stack when the context is left. Note: This is only required when not
+ * using hmac_sha1_final() that already zeroizes the structure at the
+ * end.
+ */
+static inline void hmac_sha1_zeroize_ctx(struct hmac_sha1_ctx *ctx)
+{
+	memzero_explicit(ctx, sizeof(*ctx));
+}
+
 /**
  * hmac_sha1_preparekey() - Prepare a key for HMAC-SHA1
  * @key: (output) the key structure to initialize
-- 
2.55.0

[PATCH 2/3] security: keys: trusted: always clear the hmac_sha1_ctx before returning

[Thomas Huth]

From: Thomas Huth <thuth@redhat.com>

Clear the hmac_sha1_ctx structure via __cleanup(hmac_sha1_zeroize_ctx)
to make sure that the function cannot leak any sensitive data on the
stack in case we return without hmac_sha1_final() here.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 security/keys/trusted-keys/trusted_tpm1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 13513819991e7..90536ae53d4a8 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -102,7 +102,7 @@ static inline void dump_tpm_buf(unsigned char *buf)
 static int TSS_rawhmac(unsigned char *digest, const unsigned char *key,
 		       unsigned int keylen, ...)
 {
-	struct hmac_sha1_ctx hmac_ctx;
+	struct hmac_sha1_ctx hmac_ctx __cleanup(hmac_sha1_zeroize_ctx);
 	va_list argp;
 	unsigned int dlen;
 	unsigned char *data;
-- 
2.55.0

[PATCH 3/3] lib/crypto: sha1: Use hmac_sha1_zeroize_ctx() instead of memzero_explicit()

[Thomas Huth]

From: Thomas Huth <thuth@redhat.com>

It's only cosmetics, but since we have the new hmac_sha1_zeroize_ctx()
function anyway, we can also use it here.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 lib/crypto/sha1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/crypto/sha1.c b/lib/crypto/sha1.c
index b687b89d97cb4..c4361ef77166e 100644
--- a/lib/crypto/sha1.c
+++ b/lib/crypto/sha1.c
@@ -275,7 +275,7 @@ void hmac_sha1_final(struct hmac_sha1_ctx *ctx, u8 out[SHA1_DIGEST_SIZE])
 	for (size_t i = 0; i < SHA1_DIGEST_SIZE; i += 4)
 		put_unaligned_be32(ctx->ostate.h[i / 4], out + i);
 
-	memzero_explicit(ctx, sizeof(*ctx));
+	hmac_sha1_zeroize_ctx(ctx);
 }
 EXPORT_SYMBOL_GPL(hmac_sha1_final);
 
-- 
2.55.0

Re: [PATCH 0/3] lib/crypto: Provide a function for zeroizing hmac_sha1_ctx

[Eric Biggers]

On Wed, Aug 12, 2026 at 06:33:33PM +0200, Thomas Huth wrote:
> It's maybe not worth the effort for hmac_sha1_ctx right now (since there
> is only one spot that forgot to zeroize the structure in case of errors),
> but offering a function for zeroizing the data via __cleanup might help to
> get future code into the proper shape right from the start. Thus let's
> introduce a hmac_sha1_zeroize_ctx() function now and use it in the
> appropriate spots.
> 
> Thomas Huth (3):
>   crypto: Provide a wrapper for zeroizing hmac_sha1_ctx

Subject prefix should be "lib/crypto: sha1:"

>   security: keys: trusted: always clear the hmac_sha1_ctx before
>     returning
>   lib/crypto: sha1: Use hmac_sha1_zeroize_ctx() instead of
>     memzero_explicit()
> 
>  include/crypto/sha1.h                     | 17 +++++++++++++++++
>  lib/crypto/sha1.c                         |  2 +-
>  security/keys/trusted-keys/trusted_tpm1.c |  2 +-
>  3 files changed, 19 insertions(+), 2 deletions(-)

As you probably know, SHA-1 is a bit outdated.  Will these be coming for
SHA-2 as well?  It would be nice to introduce all the APIs at the same
time so that we can make sure they're consistent.  I would actually
prioritize that over introducing callers of them right now, as that can
be done later and often requires acks from other maintainers (and they
can go through other trees as well).

- Eric

Re: [PATCH 0/3] lib/crypto: Provide a function for zeroizing hmac_sha1_ctx

[Thomas Huth]

On 13/08/2026 04.27, Eric Biggers wrote:
> On Wed, Aug 12, 2026 at 06:33:33PM +0200, Thomas Huth wrote:
>> It's maybe not worth the effort for hmac_sha1_ctx right now (since there
>> is only one spot that forgot to zeroize the structure in case of errors),
>> but offering a function for zeroizing the data via __cleanup might help to
>> get future code into the proper shape right from the start. Thus let's
>> introduce a hmac_sha1_zeroize_ctx() function now and use it in the
>> appropriate spots.
>>
>> Thomas Huth (3):
>>    crypto: Provide a wrapper for zeroizing hmac_sha1_ctx
> 
> Subject prefix should be "lib/crypto: sha1:"
> 
>>    security: keys: trusted: always clear the hmac_sha1_ctx before
>>      returning
>>    lib/crypto: sha1: Use hmac_sha1_zeroize_ctx() instead of
>>      memzero_explicit()
>>
>>   include/crypto/sha1.h                     | 17 +++++++++++++++++
>>   lib/crypto/sha1.c                         |  2 +-
>>   security/keys/trusted-keys/trusted_tpm1.c |  2 +-
>>   3 files changed, 19 insertions(+), 2 deletions(-)
> 
> As you probably know, SHA-1 is a bit outdated.  Will these be coming for
> SHA-2 as well?  It would be nice to introduce all the APIs at the same
> time so that we can make sure they're consistent.  I would actually
> prioritize that over introducing callers of them right now, as that can
> be done later and often requires acks from other maintainers (and they
> can go through other trees as well).
Yes, makes sense. I've got a patch for HMAC-SHA2 ready, too, but the patch 
that is using it on the calling site has a conflict with the smb patch that 
I already sent out, so I wanted to wait a little bit til that is merged:

  https://lore.kernel.org/lkml/20260812130152.2861834-2-thuth@redhat.com/

... but if you're fine with a series that introduces the zeroization 
functions first, without immediately introducing callers, I'm happy to 
assemble such a patch series first!

  Thomas