From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DCC04AEBED for ; Wed, 16 Sep 2026 09:50:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552262; cv=none; b=u/n9KXA6jsUsMGzWiJDG3283aQ8T9T8ccMuj6EYMtS5cG9wiepnXZ38Eig5oKdh2sj6FoO7L/TOP/FgR4ASY4VaaZM3rhm1+VJ3UpRdfedFR6krSjmzY6UENYZro4ShQMllayn0f5ahf+CUA55ztyzuFoXbkt0QWtrKzST2qn3I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552262; c=relaxed/simple; bh=qyoMQLJeiLB3R3jNlUUwjIL2eoxPZ7NoHL4nW+PB7jk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n3UbkC66an9uFrzZ+3RdlDJ6gWtwEKcXRZKGnjc2asN3OdhCKRLxTQcPYSEmrr2Ix+VT8AYMQrdkt7URkJK1VVESpAWeJMuZV0ZaHmZYXsQ72rdITHPRuMDujrDWIDgW8pCzjAL46qA32LiWALZTy0XTubapoQMF8utjYnR6ehY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Rl3i4T5u; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Rl3i4T5u" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552241; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w8OQ5sTROvl8un9Vo1lqJ9fpMZcWAu8IoU4XAMbOsgU=; b=Rl3i4T5uF+F4dejke/99pQvFZ3VyPHogLBCW8gE6ZkkmgVhQeK2daABzlx6YjD1IgzC0Od i22Se/3/unsSfxVDkEgMIQhj+xNrl0jiaFrunz1UKkochbvtMnLESCtp4682oyNkt9jnwl JR/kJ9p854BZqrze7JBcNIMKnFcQ/bw= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-139-SEUGIpghOP278deey_Amgg-1; Wed, 16 Sep 2026 05:50:35 -0400 X-MC-Unique: SEUGIpghOP278deey_Amgg-1 X-Mimecast-MFC-AGG-ID: SEUGIpghOP278deey_Amgg_1789552233 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 30BA21955E75; Wed, 16 Sep 2026 09:50:33 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1D43B1800446; Wed, 16 Sep 2026 09:50:28 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen Subject: [PATCH v4 01/13] lib/crypto: aes: Provide functions for zeroizing aes_key and aes_enckey Date: Wed, 16 Sep 2026 11:50:03 +0200 Message-ID: <20260916095022.604354-2-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Some crypto functions need to zeroize their local aes_key or aes_enckey structures after use to avoid leaking sensitive material on the stack. Provide aes_zeroize_key() and aes_zeroize_enckey() helper functions that can be used with __cleanup() to automatically zeroize the structs when they go out of scope. While we're at it, replace the memzero_explicit() calls in lib/crypto/aes.c with the new helper functions. Signed-off-by: Thomas Huth --- include/crypto/aes.h | 18 ++++++++++++++++++ lib/crypto/aes.c | 10 +++++----- 2 files changed, 23 insertions(+), 5 deletions(-) diff --git a/include/crypto/aes.h b/include/crypto/aes.h index 3279cfa546085..9fe868161e1d3 100644 --- a/include/crypto/aes.h +++ b/include/crypto/aes.h @@ -101,6 +101,15 @@ struct aes_enckey { union aes_enckey_arch k; }; =20 +/** + * aes_zeroize_enckey() - Zeroize an aes_enckey structure + * @key: The aes_enckey to zeroize + */ +static inline void aes_zeroize_enckey(struct aes_enckey *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct aes_key - An AES key prepared for encryption and decryption * @aes_enckey: Common fields and the key prepared for encryption @@ -115,6 +124,15 @@ struct aes_key { union aes_invkey_arch inv_k; }; =20 +/** + * aes_zeroize_key() - Zeroize an aes_key structure + * @key: The aes_key to zeroize + */ +static inline void aes_zeroize_key(struct aes_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /* * Please ensure that the first two fields are 16-byte aligned * relative to the start of the structure, i.e., don't move them! diff --git a/lib/crypto/aes.c b/lib/crypto/aes.c index f1549839b3de0..07c1d912ac365 100644 --- a/lib/crypto/aes.c +++ b/lib/crypto/aes.c @@ -539,7 +539,7 @@ static void __init aes_fips_test(void) if (memcmp(fips_test_data, data, sizeof(data)) !=3D 0) panic("aes: FIPS self-test failed (wrong plaintext)\n"); =20 - memzero_explicit(&key, sizeof(key)); + aes_zeroize_key(&key); } =20 #if IS_ENABLED(CONFIG_CRYPTO_LIB_AES_CBC_MACS) @@ -827,7 +827,7 @@ static void __init aes_ecb_fips_test(void) if (memcmp(fips_test_data, data, sizeof(data)) !=3D 0) panic("aes: ECB FIPS self-test failed (wrong plaintext)\n"); =20 - memzero_explicit(&key, sizeof(key)); + aes_zeroize_key(&key); } #else /* CONFIG_CRYPTO_LIB_AES_ECB */ static inline void aes_ecb_fips_test(void) @@ -1040,7 +1040,7 @@ static void __init aes_cbc_fips_test(void) if (memcmp(fips_test_data, data, sizeof(data)) !=3D 0) panic("aes: CBC FIPS self-test failed (wrong plaintext)\n"); =20 - memzero_explicit(&key, sizeof(key)); + aes_zeroize_key(&key); } =20 /* FIPS cryptographic algorithm self-test for AES-CBC-CTS */ @@ -1069,7 +1069,7 @@ static void __init aes_cbc_cts_fips_test(void) if (memcmp(ptext, data, data_len) !=3D 0) panic("aes: CBC-CTS FIPS self-test failed (wrong plaintext)\n"); =20 - memzero_explicit(&key, sizeof(key)); + aes_zeroize_key(&key); } #else /* CONFIG_CRYPTO_LIB_AES_CBC */ static inline void aes_cbc_fips_test(void) @@ -1194,7 +1194,7 @@ static void __init aes_ctr_fips_test(void) if (memcmp(fips_test_data, data, sizeof(data)) !=3D 0) panic("aes: CTR FIPS self-test failed (wrong plaintext)\n"); =20 - memzero_explicit(&key, sizeof(key)); + aes_zeroize_enckey(&key); } #else /* CONFIG_CRYPTO_LIB_AES_CTR */ static inline void aes_ctr_fips_test(void) --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0678B4B2038 for ; Wed, 16 Sep 2026 09:50:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552249; cv=none; b=nvL4xGBuRrReEt4zco5kuFTMW4GfRf979nPD1FwrSnU9xIkzpPU9nOToBfaNRrVziXu9exxrSc6al3mFeHeQjPQ478rba8tmR3xziXSUMyS2jy8mwTkxMuHSbVysQxNWLi7UH7pEgmAV6s8toFgsM2Ed9uZpKrOaDnAcDaZCSR4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552249; c=relaxed/simple; bh=Pu553ZQkM91B4VrsGc9weFb5s0yBfWGWM2iMrF015hs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BwfKegoAzB/7nCjCzDw779IIBsfpN6/cdK1vXQARLIgexhgiZA8tCwgpUIR5ALfyaO/gn0B0nWN4izqUcw1dznJbBzSp+VaIzsPB3ZjI0F8Uj+Azm83yWsVqj8ou8p8+Lng7mhzpLRHGZRPNfgem5DJhvI42cO4ZTaITfzlvzMY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BF1PObJN; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BF1PObJN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552244; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iKydTuaKi3XtSbexoPJB1tXNpcTYcsS4RpRAKal/7tc=; b=BF1PObJNeKXbD+uTUKEGwCJ6IeOXLCjVDCXwnXOkws+C0wOgg+qX6tHeJVFO6ZnPDtCjWt 3vEBYBm6boDsVLqndI6DIR3TM9rqERq4gLjXle3OMueRHgnSPpo0hRBrKKSRbTy20JaS4q Maongfj9eMJa54YCQxd3oNO3edjM6vk= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-agQkf6kLMLu0ekoPCI2NKQ-1; Wed, 16 Sep 2026 05:50:40 -0400 X-MC-Unique: agQkf6kLMLu0ekoPCI2NKQ-1 X-Mimecast-MFC-AGG-ID: agQkf6kLMLu0ekoPCI2NKQ_1789552239 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4C9F6189F8E0; Wed, 16 Sep 2026 09:50:38 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1940F1800446; Wed, 16 Sep 2026 09:50:33 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen Subject: [PATCH v4 02/13] lib/crypto: aes-xts: Provide function for zeroizing aes_xts_key Date: Wed, 16 Sep 2026 11:50:04 +0200 Message-ID: <20260916095022.604354-3-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In certain cases crypto code functions need to zeroize their local aes_xts_key structures after use to avoid leaking sensitive material. Provide an aes_xts_zeroize_key() helper function that e.g. can be used with __cleanup() to automatically zeroize the struct when it goes out of scope. While we're at it, replace the related memzero_explicit() call in lib/crypto/aes.c with a call to the new helper function. Signed-off-by: Thomas Huth --- include/crypto/aes-xts.h | 13 +++++++++++-- lib/crypto/aes.c | 2 +- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/include/crypto/aes-xts.h b/include/crypto/aes-xts.h index b9e828265e58a..3a52e1cf40b57 100644 --- a/include/crypto/aes-xts.h +++ b/include/crypto/aes-xts.h @@ -22,6 +22,15 @@ struct aes_xts_key { struct aes_enckey tweak_key; }; =20 +/** + * aes_xts_zeroize_key() - Zeroize an aes_xts_key structure + * @key: The aes_xts_key to zeroize + */ +static inline void aes_xts_zeroize_key(struct aes_xts_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * aes_xts_preparekey() - Prepare a key for AES-XTS encryption and decrypt= ion * @key: (output) The key structure to initialize @@ -30,8 +39,8 @@ struct aes_xts_key { * @flags: Optional flag XTS_FORBID_WEAK_KEYS to forbid keys whose two hal= ves * are the same. * - * Users should use memzero_explicit() to zeroize the key struct at the en= d of - * its lifetime. (But if this function fails, zeroization is unnecessary.) + * Users should use aes_xts_zeroize_key() to zeroize the key struct at the= end + * of its lifetime. (But if this function fails, zeroization is unnecessa= ry.) * * Context: Any context. * Return: diff --git a/lib/crypto/aes.c b/lib/crypto/aes.c index 07c1d912ac365..34ef5deca0a79 100644 --- a/lib/crypto/aes.c +++ b/lib/crypto/aes.c @@ -1223,7 +1223,7 @@ int aes_xts_preparekey(struct aes_xts_key *key, const= u8 *in_key, return 0; =20 out_zeroize: - memzero_explicit(key, sizeof(*key)); + aes_xts_zeroize_key(key); return err; } EXPORT_SYMBOL_GPL(aes_xts_preparekey); --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E7694AF68C for ; Wed, 16 Sep 2026 09:50:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552285; cv=none; b=hc0W7eWQVlXhQTsB/LQE/7TNICWDXFYiDMAHlN+u1Sij7NM0/Tv0GXfrbEBN3xj/sZBOrtlG6NMFU3/pjGpuj1fHIQjoXurgT2WHjQpGu0t8hstn7aWauwCFDeFH8WSdQAq/1DIeABowan8XdtcapmwqO6QAOr3WA/z4DKuwmOY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552285; c=relaxed/simple; bh=4/1kEsT70NlzkN+xrxR35Wl/GIQQI1l/UDDyNSo29h4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZHqtIfR5avegMIG2OiB4otkO5pFX/nxmXCeKr3HFsmXkaR88CD5agR0ALfB3lEltsxBe+6wICprkJJk/4mVSAs0sGDIvPIdwGa9/grKPj5D6oN2LKr487D7J1fzpkMwigFiFfqvk5EBBxikgNIb7dJ5jjMPHShjYBO75mSozZQY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=GOoshSw2; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GOoshSw2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UEdu/etGA8cxWfcQPyBtvpBW0rX8uyBFZbXJ3IuQEjE=; b=GOoshSw2pgNRxG14nb8gLynPiQ2X8NenTHUtf3yoxL9+HENlWxsWgu3Z0/QGkI1sAHWvvt q18O6z+qARq7eC6wlLceT5phP9UAJLWQVGFSPbaflADGKejS5dll6lYmjii45zZCCOuW6q t4kp+zh77hGnGyngEu3ehRTu2FdNLus= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-510-gK2KhWNXOf-mXJp3kn-Grg-1; Wed, 16 Sep 2026 05:50:45 -0400 X-MC-Unique: gK2KhWNXOf-mXJp3kn-Grg-1 X-Mimecast-MFC-AGG-ID: gK2KhWNXOf-mXJp3kn-Grg_1789552244 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E2AF518C0FF5; Wed, 16 Sep 2026 09:50:42 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 43A9F1800446; Wed, 16 Sep 2026 09:50:39 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen Subject: [PATCH v4 03/13] lib/crypto: aes-gcm: Provide functions for zeroizing aes_gcm* structures Date: Wed, 16 Sep 2026 11:50:05 +0200 Message-ID: <20260916095022.604354-4-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In certain cases crypto code needs to zeroize their local aes_gcm_key or aes_gcm_ctx structures after use to avoid leaking sensitive material. Provide aes_gcm_zeroize_key() and aes_gcm_zeroize_ctx() helper functions that e.g. can be used with __cleanup() to automatically zeroize the structures when they go out of scope. While we're at it, replace the related memzero_explicit() calls in lib/crypto/aes.c with calls to the new helper functions. Signed-off-by: Thomas Huth --- include/crypto/aes-gcm.h | 22 ++++++++++++++++++++-- lib/crypto/aes.c | 8 +++----- 2 files changed, 23 insertions(+), 7 deletions(-) diff --git a/include/crypto/aes-gcm.h b/include/crypto/aes-gcm.h index 2aee62f019891..a81b00fd8e27f 100644 --- a/include/crypto/aes-gcm.h +++ b/include/crypto/aes-gcm.h @@ -21,6 +21,15 @@ struct aes_gcm_key { size_t authtag_len; /* Length of authentication tags in bytes */ }; =20 +/** + * aes_gcm_zeroize_key() - Zeroize an aes_gcm_key structure + * @key: The aes_gcm_key to zeroize + */ +static inline void aes_gcm_zeroize_key(struct aes_gcm_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct aes_gcm_ctx - Context for incrementally en/decrypting a message */ @@ -58,6 +67,15 @@ struct aes_gcm_ctx { u64 data_len; }; =20 +/** + * aes_gcm_zeroize_ctx() - Zeroize an aes_gcm_ctx structure + * @ctx: The aes_gcm_ctx to zeroize + */ +static inline void aes_gcm_zeroize_ctx(struct aes_gcm_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + /** * aes_gcm_preparekey() - Prepare a key for AES-GCM encryption and decrypt= ion * @key: (output) The key structure to initialize @@ -66,8 +84,8 @@ struct aes_gcm_ctx { * @authtag_len: Length of the authentication tag in bytes: * 4, 8, 12, 13, 14, 15, or 16. 16 is recommended. * - * Users should use memzero_explicit() to zeroize the key struct at the en= d of - * its lifetime. (But if this function fails, zeroization is unnecessary.) + * Users should use aes_gcm_zeroize_key() to zeroize the key struct at the= end + * of its lifetime. (But if this function fails, zeroization is unnecessa= ry.) * * Context: Any context. * Return: diff --git a/lib/crypto/aes.c b/lib/crypto/aes.c index 34ef5deca0a79..0cb5d7355926e 100644 --- a/lib/crypto/aes.c +++ b/lib/crypto/aes.c @@ -1670,7 +1670,7 @@ void aes_gcm_encrypt_final(struct aes_gcm_ctx *ctx, u= 8 *authtag) ghash_final(&ctx->ghash, ctx->ctr); /* Use ctr as temp buffer */ =20 crypto_xor_cpy(authtag, ctx->ctr, ctx->j0_enc, ctx->key->authtag_len); - memzero_explicit(ctx, sizeof(*ctx)); + aes_gcm_zeroize_ctx(ctx); } EXPORT_SYMBOL_GPL(aes_gcm_encrypt_final); =20 @@ -1697,7 +1697,7 @@ int aes_gcm_decrypt_final(struct aes_gcm_ctx *ctx, co= nst u8 *authtag) -EBADMSG : 0; out: - memzero_explicit(ctx, sizeof(*ctx)); + aes_gcm_zeroize_ctx(ctx); return err; } EXPORT_SYMBOL_GPL(aes_gcm_decrypt_final); @@ -1742,7 +1742,7 @@ static void __init aes_gcm_fips_test(void) { const size_t data_len =3D sizeof(fips_test_data); u8 buf[sizeof(fips_test_data) + AES_BLOCK_SIZE]; - struct aes_gcm_key key; + struct aes_gcm_key key __cleanup(aes_gcm_zeroize_key); int err; =20 if (aes_gcm_preparekey(&key, fips_test_key, sizeof(fips_test_key), @@ -1760,8 +1760,6 @@ static void __init aes_gcm_fips_test(void) panic("aes: GCM FIPS self-test failed (decryption failed)\n"); if (memcmp(fips_test_data, buf, data_len) !=3D 0) panic("aes: GCM FIPS self-test failed (wrong plaintext)\n"); - - memzero_explicit(&key, sizeof(key)); } #else /* CONFIG_CRYPTO_LIB_AES_GCM */ static inline void aes_gcm_fips_test(void) --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E28F04AA564 for ; Wed, 16 Sep 2026 09:50:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552289; cv=none; b=sctAKd/Qcr5JXypDUtnFSDVXoCLKz+siVNfWNQCAd9suZdYAGZKvjArPFrlxV26VarZ2Qp0NYRpr00icwBwZ5xMngz0HCRLm8obZtCYoVIv2h5nqQMSEYaZbMsDl8K9RHPLenpnECultdDg8APAHDrfKfgPS77H9w6POKpBp3+E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552289; c=relaxed/simple; bh=Gauuyu1weASDOCUOi0niAJFHae1GpPUEFg2Emc3mczQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SUFeHWfHSnWgFcrWXeL8FB7BXZ4Y59jkc08YI6g2Na9/q4njzU8jmeKNtc3MCz7lB98ramEmg4HJhBud9yYqoefRORurLPube8m0ZfeNhWPiE7dh5r+XcYGmJk0FcV+l/XIDGy6kJWPxFw6HnHq1XzTkWiAIv0KD0ROdQ+7dllk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TBlalBZu; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TBlalBZu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/X0DqhKQVgSWZ6Kwg3nu2S/S85i2kZoDTzqHkKw8Nxs=; b=TBlalBZuXRrqIu7UMz3oyEH6aQxHQbrpKErHY1dx1LigdxketTrZFLGU2V5fidi2rOoMtj xsKkLPKy/8NlE8W6DrEvtznk7V9d3NRrpumbtqwJIRSxKZpxPtq8ElKC12eVh3BTKtEx3s yAffSu1bOj0KwtvpnbSuZeJQNbzkljA= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-679-8PArVGHZNeu0vL4bVgQ0Ag-1; Wed, 16 Sep 2026 05:50:50 -0400 X-MC-Unique: 8PArVGHZNeu0vL4bVgQ0Ag-1 X-Mimecast-MFC-AGG-ID: 8PArVGHZNeu0vL4bVgQ0Ag_1789552248 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2B7FB1944B17; Wed, 16 Sep 2026 09:50:47 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id DA6131800446; Wed, 16 Sep 2026 09:50:43 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen Subject: [PATCH v4 04/13] lib/crypto: aes-ccm: Provide functions for zeroizing aes_ccm* structures Date: Wed, 16 Sep 2026 11:50:06 +0200 Message-ID: <20260916095022.604354-5-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In certain cases crypto code needs to zeroize their local aes_ccm_key or aes_ccm_ctx structures after use to avoid leaking sensitive material. Provide aes_ccm_zeroize_key() and aes_ccm_zeroize_ctx() helper functions that e.g. can be used with __cleanup() to automatically zeroize the structures when they go out of scope. While we're at it, replace the related memzero_explicit() calls in lib/crypto/aes.c with calls to the new helper functions. Signed-off-by: Thomas Huth --- include/crypto/aes-ccm.h | 22 ++++++++++++++++++++-- lib/crypto/aes.c | 8 +++----- 2 files changed, 23 insertions(+), 7 deletions(-) diff --git a/include/crypto/aes-ccm.h b/include/crypto/aes-ccm.h index 8b00859ac4d6b..c52982dd91d2c 100644 --- a/include/crypto/aes-ccm.h +++ b/include/crypto/aes-ccm.h @@ -18,6 +18,15 @@ struct aes_ccm_key { size_t authtag_len; /* Length of authentication tags in bytes */ }; =20 +/** + * aes_ccm_zeroize_key() - Zeroize an aes_ccm_key structure + * @key: The aes_ccm_key to zeroize + */ +static inline void aes_ccm_zeroize_key(struct aes_ccm_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct aes_ccm_ctx - Context for incrementally en/decrypting a message */ @@ -50,6 +59,15 @@ struct aes_ccm_ctx { bool ad_padded; }; =20 +/** + * aes_ccm_zeroize_ctx() - Zeroize an aes_ccm_ctx structure + * @ctx: The aes_ccm_ctx to zeroize + */ +static inline void aes_ccm_zeroize_ctx(struct aes_ccm_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + /** * aes_ccm_preparekey() - Prepare a key for AES-CCM encryption and decrypt= ion * @key: (output) The key structure to initialize @@ -58,8 +76,8 @@ struct aes_ccm_ctx { * @authtag_len: Length of the authentication tag in bytes: * 4, 6, 8, 10, 12, 14, or 16. 16 is recommended. * - * Users should use memzero_explicit() to zeroize the key struct at the en= d of - * its lifetime. (But if this function fails, zeroization is unnecessary.) + * Users should use aes_ccm_zeroize_key() to zeroize the key struct at the= end + * of its lifetime. (But if this function fails, zeroization is unnecessa= ry.) * * Context: Any context. * Return: diff --git a/lib/crypto/aes.c b/lib/crypto/aes.c index 0cb5d7355926e..2d29adca79532 100644 --- a/lib/crypto/aes.c +++ b/lib/crypto/aes.c @@ -2011,7 +2011,7 @@ void aes_ccm_encrypt_final(struct aes_ccm_ctx *ctx, u= 8 *authtag) if (ctx->partial_len) aes_encrypt(&ctx->key->aes, ctx->mac, ctx->mac); crypto_xor_cpy(authtag, ctx->mac, ctx->s0, ctx->key->authtag_len); - memzero_explicit(ctx, sizeof(*ctx)); + aes_ccm_zeroize_ctx(ctx); } EXPORT_SYMBOL_GPL(aes_ccm_encrypt_final); =20 @@ -2032,7 +2032,7 @@ int aes_ccm_decrypt_final(struct aes_ccm_ctx *ctx, co= nst u8 *authtag) -EBADMSG : 0; out: - memzero_explicit(ctx, sizeof(*ctx)); + aes_ccm_zeroize_ctx(ctx); return err; } EXPORT_SYMBOL_GPL(aes_ccm_decrypt_final); @@ -2084,7 +2084,7 @@ static void __init aes_ccm_fips_test(void) const size_t data_len =3D sizeof(fips_test_data); const size_t nonce_len =3D 13; u8 buf[sizeof(fips_test_data) + AES_BLOCK_SIZE]; - struct aes_ccm_key key; + struct aes_ccm_key key __cleanup(aes_ccm_zeroize_key); int err; =20 if (aes_ccm_preparekey(&key, fips_test_key, sizeof(fips_test_key), @@ -2106,8 +2106,6 @@ static void __init aes_ccm_fips_test(void) panic("aes: CCM FIPS self-test failed (decryption failed)\n"); if (memcmp(fips_test_data, buf, data_len) !=3D 0) panic("aes: CCM FIPS self-test failed (wrong plaintext)\n"); - - memzero_explicit(&key, sizeof(key)); } #else /* CONFIG_CRYPTO_LIB_AES_CCM */ static inline void aes_ccm_fips_test(void) --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 777954AF9F5 for ; Wed, 16 Sep 2026 09:51:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552282; cv=none; b=OerF0kO7ClujL10nFFLjtxOIz0VtMRL7wS1In7RTxcn2klh1+iPopEBF/w4xSg7KSjUUObPn4YtyUmX8KQjcwsx1XKK0gcCPxU7fwfC9T9kOSG/tlGEyk6BqG3ebtni7TUG89Lunk8hdwOGQg6C249AqABo9QUhbrEuE82WJ6HM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552282; c=relaxed/simple; bh=d+vwqEhO/lD2ctFXZn1C2/2N9oPMH8AXcVR0UYYn2jM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UX/gmMfFZ7uY7dLD+sb/nI3y0kFcTTGILSSL9y9RoPM+glsRZ98TpC6C3tY+sTHHMwmNk87cvan0REN4SHeQZueRVk+TDGmYK8z74ubN2KJrXwXmBdBFvY2qvgUp50nOjP0iLSLPMLdXidlOrk+oD/h6yNI5tn+lVRLhuKsUJc0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=YKlI++MQ; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YKlI++MQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552261; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+JeEBAQDGBfdd7h6R58FOX2X8OCTMKwsL/hKMH91GAo=; b=YKlI++MQbdrmN41idpZQiQT1Xubu5kzfA/+3ZWEO8ou9T75W8S566Dv37uVBI4LRswkVpO zD+ST4v2ReVc48hEgQh3hJSf3mQcIbxLKYsOun4KCHiiykjV7O5kDKDvGqY86802uMGjiE elTUd0Mcjr/kheoEvBq7kdfGgP22/Vs= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-609-P9g4S4TpMWiT1wAOC-yfvg-1; Wed, 16 Sep 2026 05:50:56 -0400 X-MC-Unique: P9g4S4TpMWiT1wAOC-yfvg-1 X-Mimecast-MFC-AGG-ID: P9g4S4TpMWiT1wAOC-yfvg_1789552254 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EBA5B1829E0D; Wed, 16 Sep 2026 09:50:51 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 12E831800446; Wed, 16 Sep 2026 09:50:47 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen Subject: [PATCH v4 05/13] lib/crypto: md5: Provide a function for zeroizing hmac_md5 structures Date: Wed, 16 Sep 2026 11:50:07 +0200 Message-ID: <20260916095022.604354-6-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In certain cases crypto code functions need to zeroize their local hmac_md5_key or hmac_md5_ctx structures after use to avoid leaking sensitive material on the stack. Provide hmac_md5_zeroize_key() and hmac_md5_zeroize_ctx() helper functions that e.g. can be used with __cleanup() to automatically zeroize the structure when it goes out of scope. While we're at it, replace the related memzero_explicit() call in lib/crypto/md5.c with a call to the new helper function. Signed-off-by: Thomas Huth --- include/crypto/md5.h | 19 +++++++++++++++++++ lib/crypto/md5.c | 2 +- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/include/crypto/md5.h b/include/crypto/md5.h index c47aedfe67ecd..1ed89c15b662c 100644 --- a/include/crypto/md5.h +++ b/include/crypto/md5.h @@ -4,6 +4,7 @@ =20 #include #include +#include =20 #define MD5_DIGEST_SIZE 16 #define MD5_HMAC_BLOCK_SIZE 64 @@ -98,6 +99,15 @@ struct hmac_md5_key { struct md5_block_state ostate; }; =20 +/** + * hmac_md5_zeroize_key() - Zeroize an hmac_md5_key structure + * @key: The hmac_md5_key to zeroize + */ +static inline void hmac_md5_zeroize_key(struct hmac_md5_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct hmac_md5_ctx - Context for computing HMAC-MD5 of a message * @hash_ctx: private @@ -108,6 +118,15 @@ struct hmac_md5_ctx { struct md5_block_state ostate; }; =20 +/** + * hmac_md5_zeroize_ctx() - Zeroize an hmac_md5_ctx structure + * @ctx: The hmac_md5_ctx context to zeroize + */ +static inline void hmac_md5_zeroize_ctx(struct hmac_md5_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + /** * hmac_md5_preparekey() - Prepare a key for HMAC-MD5 * @key: (output) the key structure to initialize diff --git a/lib/crypto/md5.c b/lib/crypto/md5.c index 3d2b017a0525a..a8ee57600012d 100644 --- a/lib/crypto/md5.c +++ b/lib/crypto/md5.c @@ -271,7 +271,7 @@ void hmac_md5_final(struct hmac_md5_ctx *ctx, u8 out[MD= 5_DIGEST_SIZE]) cpu_to_le32_array(ctx->ostate.h, ARRAY_SIZE(ctx->ostate.h)); memcpy(out, ctx->ostate.h, MD5_DIGEST_SIZE); =20 - memzero_explicit(ctx, sizeof(*ctx)); + hmac_md5_zeroize_ctx(ctx); } EXPORT_SYMBOL_GPL(hmac_md5_final); =20 --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 257EF4A843F for ; Wed, 16 Sep 2026 09:51:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552292; cv=none; b=ANy2u02Fq1VvY9CpGmoaKTTCw70dML/CqvqRfFL1c7w99aaYAquAsDPOcrVanVHZqm/mfxMlanTEv08zDsbJF4ge5Wzujbj4FgbjPK6frR3susgTo12udDWAS5p1gdaLI1VoMOpJDnDQq263CEQaExWA0IpGBf8E4Y9G8xWh6ww= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552292; c=relaxed/simple; bh=jlhtz27GSry8dABqGr+SGBe1KYYN8UQBI18T52Q8X+E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P16zEO9GNho8hw9jBlLlJU1Rylaj2SZxF4WDJPgwIgBaeJ/9AIjE08ihlUlBCfBnCuLcA2fdePVPkxVWdVd48W8b2kxUZsyL0Mb/3lD7UG1yyYv6KAykH15hsudQ0Tj6AtanIJX/PBCkiNNCMaUo9zQcR74P3a0aRU3vCIb+OBg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=W8sl86PY; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="W8sl86PY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552267; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T46zRcaSlVLde9uhnONtqfo/sj56j7rPD8ZbLDPStgs=; b=W8sl86PYzrr+IvZbCfJPNrZIfeY/0/2ohXAJ/H/lKHhRXlMXo5kc7WnTEzKuVCI3mTsfYT GCXHzXW/UrzFRJeovVrMenLblrMsK7Ir5zAlRlHauQV9EFYmUEpo954EHsKPEyIvaU/cuM 91zQzItbWTZtTi641ZdSXTLtseLkTdg= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-271-pIgKSMrqMYiixOzPDfL5Rg-1; Wed, 16 Sep 2026 05:51:00 -0400 X-MC-Unique: pIgKSMrqMYiixOzPDfL5Rg-1 X-Mimecast-MFC-AGG-ID: pIgKSMrqMYiixOzPDfL5Rg_1789552259 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 56E32191FE1D; Wed, 16 Sep 2026 09:50:56 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E30DC1800345; Wed, 16 Sep 2026 09:50:52 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen Subject: [PATCH v4 06/13] lib/crypto: sm3: Provide a function for zeroizing the sm3_ctx structure Date: Wed, 16 Sep 2026 11:50:08 +0200 Message-ID: <20260916095022.604354-7-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In certain cases crypto code functions need to zeroize their local sm3_ctx structure after use to avoid leaking sensitive material. Provide a sm3_zeroize_ctx() helper function that e.g. can be used with __cleanup() to automatically zeroize the structure when it goes out of scope. While we're at it, replace the related memzero_explicit() call in lib/crypto/sm3.c with a call to the new helper function. Signed-off-by: Thomas Huth --- include/crypto/sm3.h | 10 ++++++++++ lib/crypto/sm3.c | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/include/crypto/sm3.h b/include/crypto/sm3.h index 371e8a6617054..d044ca80213ba 100644 --- a/include/crypto/sm3.h +++ b/include/crypto/sm3.h @@ -11,6 +11,7 @@ #define _CRYPTO_SM3_H =20 #include +#include =20 #define SM3_DIGEST_SIZE 32 #define SM3_BLOCK_SIZE 64 @@ -41,6 +42,15 @@ struct sm3_ctx { u8 buf[SM3_BLOCK_SIZE] __aligned(__alignof__(__be64)); }; =20 +/** + * sm3_zeroize_ctx() - Zeroize an sm3_ctx structure + * @ctx: The sm3_ctx to zeroize + */ +static inline void sm3_zeroize_ctx(struct sm3_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + /** * sm3_init() - Initialize an SM3 context for a new message * @ctx: the context to initialize diff --git a/lib/crypto/sm3.c b/lib/crypto/sm3.c index b02b8a247adf2..23059347b4493 100644 --- a/lib/crypto/sm3.c +++ b/lib/crypto/sm3.c @@ -258,7 +258,7 @@ static void __sm3_final(struct sm3_ctx *ctx, u8 out[SM3= _DIGEST_SIZE]) void sm3_final(struct sm3_ctx *ctx, u8 out[SM3_DIGEST_SIZE]) { __sm3_final(ctx, out); - memzero_explicit(ctx, sizeof(*ctx)); + sm3_zeroize_ctx(ctx); } EXPORT_SYMBOL_GPL(sm3_final); =20 --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D28F4B146F for ; Wed, 16 Sep 2026 09:51:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552305; cv=none; b=aM+cOCniompcO08pMWv30v5lzpUCotUDIeB54T3uv/5BIOkmLfV/Aq7mi8mIqWeh0c+9OchfEJRsKXm4WrffW7/z2hycO79fyU534SqKsIX7eudb48FivuUEVxkSF0P9BPbbAM3gOHIZgfz8XSt8fabOD0aEF69YCk71YG07Dvo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552305; c=relaxed/simple; bh=8Nhgl85UqN7JQx2CBcnw7jYv6wkT5XU8Jx+KGKUJbB0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Q+AtB3YpY19Jq7ytyHiAU0NW2+8FnU2jpBzpXwP7qz3v5sd3HjdZoK7GJiwFtqMQnzs5EC+x8aNF3LPXpMuJnIzd7dKJzg9hDJiVmnG9jNx1QgHUH7ZAY19AVLoFcWF+Gu65/46XXGJifMFNdjCCPM38xDer35+YDeBUwHDdYAk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=AeOKDAxE; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="AeOKDAxE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ouNZYOOt8CIaEFrfD0VxsHURoh7bbScAMyQARtiv7Dg=; b=AeOKDAxEPBktEDIVE3Inbzm45My6borjMTrWx+AAfJ+GmsTunDS3/JDVWUkZS3mhzQ6Y9v tEg/l5u8ML7ZORvL5cXVD96/ZjyIuj0muQcoPBSp20VYvldDnAG80ick116pY9UcvSPWfV mmZw6KlJ4EoP09+SKtFfPG8nUnuVPc0= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-502-Jt1XCjSpOPSY1HZei2dzpA-1; Wed, 16 Sep 2026 05:51:06 -0400 X-MC-Unique: Jt1XCjSpOPSY1HZei2dzpA-1 X-Mimecast-MFC-AGG-ID: Jt1XCjSpOPSY1HZei2dzpA_1789552265 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 73702196F75A; Wed, 16 Sep 2026 09:51:01 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7B65B1800446; Wed, 16 Sep 2026 09:50:57 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen Subject: [PATCH v4 07/13] lib/crypto: blake2: Provide functions for zeroizing blake2*_ctx structures Date: Wed, 16 Sep 2026 11:50:09 +0200 Message-ID: <20260916095022.604354-8-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In certain cases crypto code needs to zeroize their local blake2b_ctx or blake2s_ctx structures after use to avoid leaking sensitive material. Provide blake2b_zeroize_ctx() and blake2s_zeroize_ctx() helper functions that e.g. can be used with __cleanup() to automatically zeroize the structures when they go out of scope. While we're at it, replace the related memzero_explicit() calls in lib/crypto/blake2*.c with calls to the new helper functions. Signed-off-by: Thomas Huth --- include/crypto/blake2b.h | 9 +++++++++ include/crypto/blake2s.h | 9 +++++++++ lib/crypto/blake2b.c | 2 +- lib/crypto/blake2s.c | 2 +- 4 files changed, 20 insertions(+), 2 deletions(-) diff --git a/include/crypto/blake2b.h b/include/crypto/blake2b.h index 3bc37fd103a7a..eda1604bce780 100644 --- a/include/crypto/blake2b.h +++ b/include/crypto/blake2b.h @@ -37,6 +37,15 @@ struct blake2b_ctx { unsigned int outlen; }; =20 +/** + * blake2b_zeroize_ctx() - Zeroize a blake2b_ctx structure + * @ctx: The blake2b_ctx to zeroize + */ +static inline void blake2b_zeroize_ctx(struct blake2b_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + enum blake2b_iv { BLAKE2B_IV0 =3D 0x6A09E667F3BCC908ULL, BLAKE2B_IV1 =3D 0xBB67AE8584CAA73BULL, diff --git a/include/crypto/blake2s.h b/include/crypto/blake2s.h index 648cb78243588..bb4e6870ed196 100644 --- a/include/crypto/blake2s.h +++ b/include/crypto/blake2s.h @@ -41,6 +41,15 @@ struct blake2s_ctx { unsigned int outlen; }; =20 +/** + * blake2s_zeroize_ctx() - Zeroize a blake2s_ctx structure + * @ctx: The blake2s_ctx to zeroize + */ +static inline void blake2s_zeroize_ctx(struct blake2s_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + enum blake2s_iv { BLAKE2S_IV0 =3D 0x6A09E667UL, BLAKE2S_IV1 =3D 0xBB67AE85UL, diff --git a/lib/crypto/blake2b.c b/lib/crypto/blake2b.c index 581b7f8486fae..55d6c437f311f 100644 --- a/lib/crypto/blake2b.c +++ b/lib/crypto/blake2b.c @@ -148,7 +148,7 @@ void blake2b_final(struct blake2b_ctx *ctx, u8 *out) blake2b_compress(ctx, ctx->buf, 1, ctx->buflen); cpu_to_le64_array(ctx->h, ARRAY_SIZE(ctx->h)); memcpy(out, ctx->h, ctx->outlen); - memzero_explicit(ctx, sizeof(*ctx)); + blake2b_zeroize_ctx(ctx); } EXPORT_SYMBOL(blake2b_final); =20 diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c index 71578a0847423..24f7f34334b01 100644 --- a/lib/crypto/blake2s.c +++ b/lib/crypto/blake2s.c @@ -142,7 +142,7 @@ void blake2s_final(struct blake2s_ctx *ctx, u8 *out) blake2s_compress(ctx, ctx->buf, 1, ctx->buflen); cpu_to_le32_array(ctx->h, ARRAY_SIZE(ctx->h)); memcpy(out, ctx->h, ctx->outlen); - memzero_explicit(ctx, sizeof(*ctx)); + blake2s_zeroize_ctx(ctx); } EXPORT_SYMBOL(blake2s_final); =20 --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BB2D4AEBD8 for ; Wed, 16 Sep 2026 09:51:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552305; cv=none; b=kf9/27j9WPESJNO6Og/LvM/jbIWObQD+sU9On2Xxpqu6I8SSko8sgK+bnIQYARdduM2hDsGMGQzUf/6iOs06lMuJbf/miQDRrSBn6C3lWBftxA4MNeGyzdKfd4q2qnsVpMpDaAQ+a1oeiL7RV2g65fNE/UQ3VLBE2s6lSd9jJPg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552305; c=relaxed/simple; bh=SMz1n2qZSUfU+2cgkcz49kZ4uQA0DD7hBcMOHyDLDOg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gth1iLTUER27pUY6N1cn+gNYC6+ZBDOgl36ToZfXQQfWD188wlYmiGJPEzLE0Da5CCtmWHSIJEnrcSRQRro/qADUfKqJCj/v37cDafunq6XO487d5J9Tg3rR3SFxfpP/NqxxEwmYsB41zJF8XQZNWkqa1kjWnunq3nXxSrP2WLE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=L6oGpZzd; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="L6oGpZzd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552284; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YFi1wI0axV9T/N/bsBEiFja16TRKzsIA5VOlO65mHUM=; b=L6oGpZzdEDWIe8vsBoiC4GYvsmkhGCelYbFMoXbtxJ/zM4DUV2W1gSwqoJXm1UtWc0QcZU k0d4h9CnftV83/yGiAurT0is6Dd0SOnRvxcK+R9TQ/WKY8wveE87zgS0q4lJ7a9cVtUiBH +IEhOJPM+4yKqLuMwJDWquAfAyf9lZc= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-91-emr1cyZJM4GTR-P-DOamIg-1; Wed, 16 Sep 2026 05:51:10 -0400 X-MC-Unique: emr1cyZJM4GTR-P-DOamIg-1 X-Mimecast-MFC-AGG-ID: emr1cyZJM4GTR-P-DOamIg_1789552268 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 009AB195606C; Wed, 16 Sep 2026 09:51:06 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 747871800352; Wed, 16 Sep 2026 09:51:02 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen Subject: [PATCH v4 08/13] lib/crypto: sha1: Provide functions for zeroizing hmac_sha1 structures Date: Wed, 16 Sep 2026 11:50:10 +0200 Message-ID: <20260916095022.604354-9-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In certain cases crypto code needs to zeroize their local hmac_sha1_key or hmac_sha1_ctx structures after use to avoid leaking sensitive material. Provide hmac_sha1_zeroize_key() and hmac_sha1_zeroize_ctx() helper functions that e.g. can be used with __cleanup() to automatically zeroize the structures when they go out of scope. While we're at it, replace the related memzero_explicit() call in lib/crypto/sha1.c with a call to the new helper function. Signed-off-by: Thomas Huth --- include/crypto/sha1.h | 19 +++++++++++++++++++ lib/crypto/sha1.c | 2 +- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/include/crypto/sha1.h b/include/crypto/sha1.h index 4d973e016cd69..bc0046bffeaee 100644 --- a/include/crypto/sha1.h +++ b/include/crypto/sha1.h @@ -7,6 +7,7 @@ #define _CRYPTO_SHA1_H =20 #include +#include =20 #define SHA1_DIGEST_SIZE 20 #define SHA1_BLOCK_SIZE 64 @@ -96,6 +97,15 @@ struct hmac_sha1_key { struct sha1_block_state ostate; }; =20 +/** + * hmac_sha1_zeroize_key() - Zeroize an hmac_sha1_key structure + * @key: The hmac_sha1_key to zeroize + */ +static inline void hmac_sha1_zeroize_key(struct hmac_sha1_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct hmac_sha1_ctx - Context for computing HMAC-SHA1 of a message * @sha_ctx: private @@ -106,6 +116,15 @@ struct hmac_sha1_ctx { struct sha1_block_state ostate; }; =20 +/** + * hmac_sha1_zeroize_ctx() - Zeroize an hmac_sha1_ctx structure + * @ctx: The hmac_sha1_ctx context to zeroize + */ +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 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 =3D 0; i < SHA1_DIGEST_SIZE; i +=3D 4) put_unaligned_be32(ctx->ostate.h[i / 4], out + i); =20 - memzero_explicit(ctx, sizeof(*ctx)); + hmac_sha1_zeroize_ctx(ctx); } EXPORT_SYMBOL_GPL(hmac_sha1_final); =20 --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E0CD94B0C88 for ; Wed, 16 Sep 2026 09:51:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552335; cv=none; b=Jp+EV4wrEIvhZ0q7NtcKr8UtWXkTza7QcX0bUjNiQeaDgyxy0w8KHPc8R26X3wt5isUwRD+qwaF9vIPf7DDhciVnlkks5X8B2pn/8vgZZ0x7yLO25irgd5US5G+FOq/cRbQtvHw3kjpY/Io0BOSGIMjDqRRcc03YILMmyJsnVcA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552335; c=relaxed/simple; bh=YA+a6CCA1zWdQPcieNEuLQ0mIwRn0Ck7WsDOY4ql94Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G7fvr95fqlYDAXj11Tekt5CSpdjkXgJ6R5fKucBB8uFU2IENpe8tkFdEyRADHrcQeCcI2h74ObT/4uJDqwU2v7tyo714+OrFXJ3WvQ7lZt8U2JTrXORziua0bGkgLlq3lGzgA/A0ajhcSotISkQNiOhZ6dRuavhbxaqfBf5xumQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KA/2YiJf; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KA/2YiJf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552280; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FeWcXK9/x+ZPPaC++IgCQ9jS/VWtgj79RgI0CVq94cU=; b=KA/2YiJfDI5z5Tb0+9S9i5OwaAApl2+sF9ZZIO69akxlchzHBiRTMQonw3CaQ7+jG144Ic OoLDgQZJgVl3BrRr3yjXAheQ0+sVYqSkh0v4wteOLWpok1loF5EfQAb+H6OWspdIfwgX7p fY77YpO1yu6V24DHC548RLQjJYqu+h4= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-490-QFumBAnuPfmT3gOSUAZqmg-1; Wed, 16 Sep 2026 05:51:16 -0400 X-MC-Unique: QFumBAnuPfmT3gOSUAZqmg-1 X-Mimecast-MFC-AGG-ID: QFumBAnuPfmT3gOSUAZqmg_1789552274 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 79A9F18011DC; Wed, 16 Sep 2026 09:51:13 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CD2991800446; Wed, 16 Sep 2026 09:51:06 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov , James Bottomley , Jarkko Sakkinen , Mimi Zohar , David Howells , Paul Moore , James Morris , "Serge E. Hallyn" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org Subject: [PATCH v4 09/13] security: keys: trusted: always clear the hmac_sha1_ctx before returning Date: Wed, 16 Sep 2026 11:50:11 +0200 Message-ID: <20260916095022.604354-10-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Clear the hmac_sha1_ctx structure via __cleanup(hmac_sha1_zeroize_ctx) to make sure that the function does not leak sensitive data on the stack when returning without calling hmac_sha1_final(). Reviewed-by: Jarkko Sakkinen Signed-off-by: Thomas Huth --- 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/trus= ted-keys/trusted_tpm1.c index bf0bf7f369705..e5a904b5c1946 100644 --- a/security/keys/trusted-keys/trusted_tpm1.c +++ b/security/keys/trusted-keys/trusted_tpm1.c @@ -101,7 +101,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; --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 149F64AB1A0 for ; Wed, 16 Sep 2026 09:51:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552320; cv=none; b=VfUWrHMZgQqHOD0FGb/E0CdChNExnfLvvjG5TFJJm0c84Ivls6omM/xr1QbV7a9JvxeCpiaXlR3qYPQRNbGegngnJrMeuNPpoz0dwMJOC3QU7UWpj4VIQSTwjpjo3fny+uvPx/hUZv0a7l/sIdLMCMzF2FiE0OyftJrmpynTZDE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552320; c=relaxed/simple; bh=E6KPxvJHH1VHldmIFR1xanm+ALnTwrvx3H+X++MBV5U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nLu0vgZi1zQZRiSwWdaBW+u0ka6wz+JurRrOX3N/cHJ8okzcrupXnJt/cX87xOMfkoF9Kcg2G0FZrQTgfKJAyUX7heCMg62H1TXe1F9uvbfsmSt5VzB/1G8tmbY+abYVDHwrp43O/HakAsLkpbyk5skR95z3AOLwV6O4WGrhLQk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=fOrJCv5D; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="fOrJCv5D" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552285; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A1COWvN1IxP74U37pvhe+s+4DbmU+5bH+TwCyZ5ozBA=; b=fOrJCv5DehyCnN5vcPl0xECFm3773kWbb3DRUGo73drMKrVzcBsiJvNcQeYATNafAN9zq9 meDrJJ20cI4ahKQrXJcox7SzZtjjvza3oOjLM7Wm9EZjUmaomsPP4rmz+ug70v44MRtIvy zNZHktl4BcIeh7vBXmUjgN2sV49v4iI= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-631-YwrMlN3-M7KbdZtlt_MnxQ-1; Wed, 16 Sep 2026 05:51:20 -0400 X-MC-Unique: YwrMlN3-M7KbdZtlt_MnxQ-1 X-Mimecast-MFC-AGG-ID: YwrMlN3-M7KbdZtlt_MnxQ_1789552278 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E5B5D1955F2A; Wed, 16 Sep 2026 09:51:17 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4210B1800446; Wed, 16 Sep 2026 09:51:14 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, "H. Peter Anvin" Subject: [PATCH v4 10/13] x86/purgatory: Compile purgatory with -D__NO_FORTIFY Date: Wed, 16 Sep 2026 11:50:12 +0200 Message-ID: <20260916095022.604354-11-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 A subsequent patch will add #include to to use memzero_explicit() there. This will introduce a conflict with the purgatory code: purgatory.c includes both, the header and the arch/x86/boot/string.h header. The latter provides its own prototypes for a lot of string functions which clash with the fortified macros from , causing the compiler to emit errors like this: In file included from .../linux/include/linux/string.h:383, from .../linux/include/crypto/sha2.h:10, from .../linux/arch/x86/purgatory/purgatory.c:14: .../linux/include/linux/fortify-string.h:576:63: error: expected identifie= r or =E2=80=98(=E2=80=99 before =E2=80=98{=E2=80=99 token 576 | p_size_field, q_size_field, op) ({ = \ | ^ .../linux/include/linux/fortify-string.h:644:27: note: in expansion of mac= ro =E2=80=98__fortify_memcpy_chk=E2=80=99 644 | #define memmove(p, q, s) __fortify_memcpy_chk(p, q, s, = \ | ^~~~~~~~~~~~~~~~~~~~ .../linux/arch/x86/purgatory/../boot/string.h:11:7: note: in expansion of = macro =E2=80=98memmove=E2=80=99 11 | void *memmove(void *dst, const void *src, size_t len); | ^~~~~~~ .../linux/include/linux/fortify-string.h:208:9: error: expected identifier= or =E2=80=98(=E2=80=99 before =E2=80=98__builtin_choose_expr=E2=80=99 208 | __builtin_choose_expr(__is_constexpr(__builtin_strlen(p)),= \ | ^~~~~~~~~~~~~~~~~~~~~ ./linux/arch/x86/purgatory/../boot/string.h:23:15: note: in expansion of m= acro =E2=80=98strlen=E2=80=99 23 | extern size_t strlen(const char *s); | ^~~~~~ To avoid the problem, let's compile the code in the purgatory with -D__NO_FORTIFY, so can properly be included from headers like in the purgatory, too. Signed-off-by: Thomas Huth --- arch/x86/purgatory/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile index 5ce1d42630000..cde8463b4d841 100644 --- a/arch/x86/purgatory/Makefile +++ b/arch/x86/purgatory/Makefile @@ -11,7 +11,7 @@ $(obj)/string.o: $(srctree)/arch/x86/boot/compressed/stri= ng.c FORCE $(obj)/sha256.o: $(srctree)/lib/crypto/sha256.c FORCE $(call if_changed_rule,cc_o_c) =20 -CFLAGS_sha256.o :=3D -D__DISABLE_EXPORTS -D__NO_FORTIFY +CFLAGS_sha256.o :=3D -D__DISABLE_EXPORTS =20 # When profile-guided optimization is enabled, llvm emits two different # overlapping text sections, which is not supported by kexec. Remove profi= le @@ -37,6 +37,7 @@ PURGATORY_CFLAGS :=3D -mcmodel=3Dsmall -ffreestanding -fn= o-zero-initialized-in-bss - PURGATORY_CFLAGS +=3D -fpic -fvisibility=3Dhidden PURGATORY_CFLAGS +=3D $(DISABLE_KSTACK_ERASE) -DDISABLE_BRANCH_PROFILING PURGATORY_CFLAGS +=3D -fno-stack-protector +PURGATORY_CFLAGS +=3D -D__NO_FORTIFY =20 # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. Th= at # in turn leaves some undefined symbols like __fentry__ in purgatory and n= ot --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 298174AF69F for ; Wed, 16 Sep 2026 09:51:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552309; cv=none; b=U8k+sWlBiZOrrqghNGRkaNjq9MJvS1pEovvWqNSjsa7s3WXNamgKHcJp7iVICgOaIl1k5IEsvWPXZ7wt9/1pIY7Hr9NiB9etk0rjfs4CSAosG8zTwYGsT+nLt6d+mPmq+2JnfasuWqUYvIzm/Od1zAqRRwuUJLewv2ZJWmhbvoU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552309; c=relaxed/simple; bh=Pznk8hfVuVukVfclBPzbhLEaJi6ZtK/4mQJu/n1NEDs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PFuiPLjOWGy3hP5C3ElJb+QjY5JhBye/1moKurlKwftu/jjqjbFlCikPkv+IXGtQgEGlZnvIR0c9woZzABGXj2kEUYhtM9nJgPiDnSg+Ryn9rzdlNWjmAX/C5T00UR3WI/h/4KD9jhP2phqNK0m34Zd4SAPCmZ92qO/5l0dgFvQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=aKUC+0CK; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aKUC+0CK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552287; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dAu1bQF4/jUeSXArCSj5+nJuZ/vxHgx8HbK6kP4IS9s=; b=aKUC+0CKe5jw+9GZTsuhjPG2G9KCWY2eb+hpoQxeCpbLDKj+/uNupXd5yRZS06o4xe2GiG KhI3yRD7+pNSqwx9voJUuo2/Z4AcnlTVoWIgvMjnMO45sw2dkTJE6IKC4D9Mn28wXO/n2r 13u2a67R1I/IOrygQ0DzmvuUZpbv3nk= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-606-afO72ag2MPaTPknHrn1usQ-1; Wed, 16 Sep 2026 05:51:24 -0400 X-MC-Unique: afO72ag2MPaTPknHrn1usQ-1 X-Mimecast-MFC-AGG-ID: afO72ag2MPaTPknHrn1usQ_1789552282 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7DE201954B27; Wed, 16 Sep 2026 09:51:22 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B41561800446; Wed, 16 Sep 2026 09:51:18 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , Namjae Jeon Subject: [PATCH v4 11/13] lib/crypto: sha2: Provide functions for zeroizing SHA2 hmac_sha* structures Date: Wed, 16 Sep 2026 11:50:13 +0200 Message-ID: <20260916095022.604354-12-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In certain cases crypto code functions need to zeroize their local SHA2 hmac_sha*_key or hmac_sha*_ctx structures after use to avoid leaking sensitive material on the stack. Provide hmac_sha*_zeroize_key() and hmac_sha*_zeroize_ctx() helper functions that can be used with __cleanup() to automatically zeroize the structure when it goes out of scope. Reviewed-by: Namjae Jeon Signed-off-by: Thomas Huth --- include/crypto/sha2.h | 73 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/include/crypto/sha2.h b/include/crypto/sha2.h index 7bb8fe169daf2..22fbc37ae8407 100644 --- a/include/crypto/sha2.h +++ b/include/crypto/sha2.h @@ -7,6 +7,7 @@ #define _CRYPTO_SHA2_H =20 #include +#include =20 #define SHA224_DIGEST_SIZE 28 #define SHA224_BLOCK_SIZE 64 @@ -210,6 +211,15 @@ struct hmac_sha224_key { struct __hmac_sha256_key key; }; =20 +/** + * hmac_sha224_zeroize_key() - Zeroize an hmac_sha224_key structure + * @key: The hmac_sha224_key to zeroize + */ +static inline void hmac_sha224_zeroize_key(struct hmac_sha224_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct hmac_sha224_ctx - Context for computing HMAC-SHA224 of a message * @ctx: private @@ -218,6 +228,15 @@ struct hmac_sha224_ctx { struct __hmac_sha256_ctx ctx; }; =20 +/** + * hmac_sha224_zeroize_ctx() - Zeroize an hmac_sha224_ctx structure + * @ctx: The hmac_sha224_ctx context to zeroize + */ +static inline void hmac_sha224_zeroize_ctx(struct hmac_sha224_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + /** * hmac_sha224_preparekey() - Prepare a key for HMAC-SHA224 * @key: (output) the key structure to initialize @@ -414,6 +433,15 @@ struct hmac_sha256_key { struct __hmac_sha256_key key; }; =20 +/** + * hmac_sha256_zeroize_key() - Zeroize an hmac_sha256_key structure + * @key: The hmac_sha256_key to zeroize + */ +static inline void hmac_sha256_zeroize_key(struct hmac_sha256_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct hmac_sha256_ctx - Context for computing HMAC-SHA256 of a message * @ctx: private @@ -422,6 +450,15 @@ struct hmac_sha256_ctx { struct __hmac_sha256_ctx ctx; }; =20 +/** + * hmac_sha256_zeroize_ctx() - Zeroize an hmac_sha256_ctx structure + * @ctx: The hmac_sha256_ctx context to zeroize + */ +static inline void hmac_sha256_zeroize_ctx(struct hmac_sha256_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + /** * hmac_sha256_preparekey() - Prepare a key for HMAC-SHA256 * @key: (output) the key structure to initialize @@ -623,6 +660,15 @@ struct hmac_sha384_key { struct __hmac_sha512_key key; }; =20 +/** + * hmac_sha384_zeroize_key() - Zeroize an hmac_sha384_key structure + * @key: The hmac_sha384_key to zeroize + */ +static inline void hmac_sha384_zeroize_key(struct hmac_sha384_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct hmac_sha384_ctx - Context for computing HMAC-SHA384 of a message * @ctx: private @@ -631,6 +677,15 @@ struct hmac_sha384_ctx { struct __hmac_sha512_ctx ctx; }; =20 +/** + * hmac_sha384_zeroize_ctx() - Zeroize an hmac_sha384_ctx structure + * @ctx: The hmac_sha384_ctx context to zeroize + */ +static inline void hmac_sha384_zeroize_ctx(struct hmac_sha384_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + /** * hmac_sha384_preparekey() - Prepare a key for HMAC-SHA384 * @key: (output) the key structure to initialize @@ -798,6 +853,15 @@ struct hmac_sha512_key { struct __hmac_sha512_key key; }; =20 +/** + * hmac_sha512_zeroize_key() - Zeroize an hmac_sha512_key structure + * @key: The hmac_sha512_key to zeroize + */ +static inline void hmac_sha512_zeroize_key(struct hmac_sha512_key *key) +{ + memzero_explicit(key, sizeof(*key)); +} + /** * struct hmac_sha512_ctx - Context for computing HMAC-SHA512 of a message * @ctx: private @@ -806,6 +870,15 @@ struct hmac_sha512_ctx { struct __hmac_sha512_ctx ctx; }; =20 +/** + * hmac_sha512_zeroize_ctx() - Zeroize an hmac_sha512_ctx structure + * @ctx: The hmac_sha512_ctx context to zeroize + */ +static inline void hmac_sha512_zeroize_ctx(struct hmac_sha512_ctx *ctx) +{ + memzero_explicit(ctx, sizeof(*ctx)); +} + /** * hmac_sha512_preparekey() - Prepare a key for HMAC-SHA512 * @key: (output) the key structure to initialize --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 986804AF167 for ; Wed, 16 Sep 2026 09:51:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552303; cv=none; b=Bmg4Wck6E97eY5/B9bjuN1wLg2U3fjB7Bb5Oima+6UzNg6uYpVhnlDCGDGgwfEn1S0EJYuMFAEuTOjVoN3Sw+9hmL2ZS3CGO97+CRUDzn4yLSOE5R1vDPiraPVNdTK+McxG+4opEpVjEaiWXMy9jnU1bBOgMj4PPiMGo6it4Tuc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552303; c=relaxed/simple; bh=HsLRaYuEbq7ZzzRNl6uSIAKV4rQlZ2M6v1OhzKK4PeA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YlKNwdccmcmXH4n6TVONjs4V/Bp2Fhk4Y6DTTAKzv+UuSkdC25+tWaEkNMyDKxoH61LTJ3b4bW8ZyXM/qtd/z5/fGWOyOrDN0Wit9g8cbR8D9EZ5k4ln008D4MAEtdfc9y2yV+9PR/VmiRzYZXdpv9kz7l1z341KCJkE7UwW5IE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=gy/CM2vE; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gy/CM2vE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552297; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hUSOoW0g30UFVhZc7yIBkWk1BVCAbM29mk2RKcbK+JY=; b=gy/CM2vEMdBFAlkWT1h9m+VA7mZvSK7TkiXBGPgtHZWWFXwKc0HZ0d2ZHhNJLrt5oi9eLn zXwHkwtURn1z9MLjDZEbj92scsCJVIhUp4S+nj+k1YYJUoG6jltBQ3nOMXBQUdZ/efPFO6 BehBOwyovOv6Kt4eUgw2pxOOyigr1xM= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-398-eQhTA5pfOC-RaQf07cCbfQ-1; Wed, 16 Sep 2026 05:51:32 -0400 X-MC-Unique: eQhTA5pfOC-RaQf07cCbfQ-1 X-Mimecast-MFC-AGG-ID: eQhTA5pfOC-RaQf07cCbfQ_1789552289 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0B7D11954227; Wed, 16 Sep 2026 09:51:29 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 50C471800446; Wed, 16 Sep 2026 09:51:23 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov , Paulo Alcantara , Namjae Jeon Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Bharath SM , linux-cifs@vger.kernel.org, samba-technical@lists.samba.org Subject: [PATCH v4 12/13] smb: client: Use hmac_sha256_zeroize_ctx function to clear hmac_sha256_ctx Date: Wed, 16 Sep 2026 11:50:14 +0200 Message-ID: <20260916095022.604354-13-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" It's just cosmetics, but now that we have a helper function for clearing hmac_sha256_ctx with a __cleanup() statement, we can also use it in the smb client code for good measure. Signed-off-by: Thomas Huth --- fs/smb/client/smb2transport.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/smb/client/smb2transport.c b/fs/smb/client/smb2transport.c index c407f30e00401..080864b24a0c5 100644 --- a/fs/smb/client/smb2transport.c +++ b/fs/smb/client/smb2transport.c @@ -212,7 +212,7 @@ smb2_calc_signature(struct smb_rqst *rqst, struct TCP_S= erver_Info *server) unsigned char smb2_signature[SMB2_HMACSHA256_SIZE]; struct kvec *iov =3D rqst->rq_iov; struct smb2_hdr *shdr =3D (struct smb2_hdr *)iov[0].iov_base; - struct hmac_sha256_ctx hmac_ctx; + struct hmac_sha256_ctx hmac_ctx __cleanup(hmac_sha256_zeroize_ctx); struct smb_rqst drqst; __u64 sid =3D le64_to_cpu(shdr->SessionId); u8 key[SMB2_NTLMV2_SESSKEY_SIZE]; @@ -250,7 +250,6 @@ smb2_calc_signature(struct smb_rqst *rqst, struct TCP_S= erver_Info *server) memcpy(shdr->Signature, smb2_signature, SMB2_SIGNATURE_SIZE); =20 memzero_explicit(key, sizeof(key)); - memzero_explicit(&hmac_ctx, sizeof(hmac_ctx)); return rc; } =20 --=20 2.55.0 From nobody Fri Sep 25 05:29:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E86C34B1269 for ; Wed, 16 Sep 2026 09:51:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552325; cv=none; b=F0aQpMZbuYodazaOHi97ERwoc5ia3FmHqzidRu8a0doJmZQOwxYlq/kpGYjOK+cM/6wxDI19vksV1kxdbVW92KQG8oOL/FO97vG+wJpzm1ShpRBZspLt4wLQkCLTpfta9RB4x051z2jKVu4qtcfM+v2qZyCH3ZaoqhVBo8H7IAk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789552325; c=relaxed/simple; bh=t0TvZPm4bc6UM2noQD4veZ5BAJamKZP7g/xTbhK+DRE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F7bOGec0yCFytI/BlkqLMFk6dwRS9SjUB4B6fSpaTwf6PbwK2nnHPqE+VOnkJ4Vkk9gRkE/cVfW6rlJPHtpqrO5gOOj6KfDA2P1ngSRKm2nTb5kMwQen/4Zm6/bJCha5McQDXKeu2ofISZIQbUAhw8V4zGyF3sL1M6PdDK/A85Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=YYdwPnF9; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YYdwPnF9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789552301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mPzM/yoe+rotV16ewh/fuu8dlIcugVfAA9aWoS3G1cQ=; b=YYdwPnF94IFDjGvxtEUCdRWK5klfrjA1pkcub73y+yHdgXUbCJnsI9Fuin+oACJxDKCWuN gjXkomXzSwgy9/X/aTIjRVbp0yPTa625yRqvrokX3PlEHGF3zJMiGjfcAT0dRoHfOwvBfx xJXqFAiHxgrp87sRlrbF21SccatBRso= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-7-dGwiUwAuM-iXxhhOynUJ5A-1; Wed, 16 Sep 2026 05:51:37 -0400 X-MC-Unique: dGwiUwAuM-iXxhhOynUJ5A-1 X-Mimecast-MFC-AGG-ID: dGwiUwAuM-iXxhhOynUJ5A_1789552295 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 199EA195DE37; Wed, 16 Sep 2026 09:51:35 +0000 (UTC) Received: from thuth-p1g4.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 188651800446; Wed, 16 Sep 2026 09:51:29 +0000 (UTC) From: Thomas Huth To: Eric Biggers , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Ard Biesheuvel , Borislav Petkov , Jonathan Corbet Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , Shuah Khan , Randy Dunlap , linux-doc@vger.kernel.org Subject: [PATCH v4 13/13] lib/crypto: Add documentation about zeroization of key and context data Date: Wed, 16 Sep 2026 11:50:15 +0200 Message-ID: <20260916095022.604354-14-thuth@redhat.com> In-Reply-To: <20260916095022.604354-1-thuth@redhat.com> References: <20260916095022.604354-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Add a central document about zeroization in libcrypto so we don't have to repeat this information in the individual kernel docs of the zeroization functions all over the place. Signed-off-by: Thomas Huth --- .../crypto/libcrypto-zeroization.rst | 150 ++++++++++++++++++ Documentation/crypto/libcrypto.rst | 1 + 2 files changed, 151 insertions(+) create mode 100644 Documentation/crypto/libcrypto-zeroization.rst diff --git a/Documentation/crypto/libcrypto-zeroization.rst b/Documentation= /crypto/libcrypto-zeroization.rst new file mode 100644 index 0000000000000..76b6506711634 --- /dev/null +++ b/Documentation/crypto/libcrypto-zeroization.rst @@ -0,0 +1,150 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Crypto Key Zeroization +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +This document describes the conventions for zeroizing crypto structures in= the +kernel. + +Note: the kernel follows traditional cryptographic terminology by using +the term "zeroizing" to mean erasing sensitive parameters to prevent +their disclosure if the system is later compromised. This distinguishes +it from zeroing memory for other purposes such as initialization. + +.. contents:: + +Overview +-------- + +Cryptographic key material and intermediate state (such as HMAC contexts) = must +be zeroized after use to prevent sensitive data from lingering on the stac= k or +heap, where it could be leaked through memory disclosure vulnerabilities, +crash dumps, or cold-boot attacks. + +For memory that has been allocated with kmalloc() or a similar function, +kfree_sensitive() should be used instead of kfree() to release the memory. + +For other cases, the kernel provides memzero_explicit() for clearing the +memory. Unlike plain memset(), memzero_explicit() is guaranteed not +to be optimized away by the compiler, even when the memory being cleared +appears to be dead. + +The crypto library builds on memzero_explicit() by providing typed +zeroization helpers for each key and context structure. These helpers ser= ve +two purposes: + +1. They make __cleanup() annotations possible, so that structures on + the stack are automatically zeroized when they go out of scope. + +2. They improve readability by replacing ``memzero_explicit(&key, sizeof(k= ey))`` + with a self-documenting call like ``aes_zeroize_key(&key)``. + + +What to zeroize +--------------- + +The following types of structures hold sensitive material and should be +zeroized after use: + +- **Key structures** (e.g. ``struct aes_key``, ``struct hmac_sha256_key``): + contain expanded round keys or prepared key material. + +- **HMAC/MAC context structures** (e.g. ``struct hmac_sha256_ctx``, + ``struct aes_cmac_ctx``): contain inner and outer hash states derived fr= om + the key. + +- **Hash context structures** (e.g. ``struct sha256_ctx``): may contain + sensitive data being hashed. + +Not all of these require explicit cleanup by callers. Many ``..._final()`` +functions already zeroize their context internally (see `Automatic vs. man= ual +zeroization`_ below). + + +Zeroization helpers +------------------- + +Each crypto structure that callers may need to zeroize should have a +corresponding inline helper function. The naming convention is:: + + _zeroize_(struct _ *p); + +For example:: + + void aes_zeroize_key(struct aes_key *key); + void aes_zeroize_enckey(struct aes_enckey *key); + void hmac_sha256_zeroize_ctx(struct hmac_sha256_ctx *ctx); + void aes_cmac_zeroize_key(struct aes_cmac_key *key); + void aes_cmac_zeroize_ctx(struct aes_cmac_ctx *ctx); + +Each helper is a ``static inline`` function in the algorithm's header that +wraps ``memzero_explicit()``, for example:: + + static inline void hmac_sha256_zeroize_ctx(struct hmac_sha256_ctx *ctx) + { + memzero_explicit(ctx, sizeof(*ctx)); + } + + +Using __cleanup for automatic zeroization +----------------------------------------- + +The preferred way to zeroize stack-allocated key and context structures is +with the __cleanup() attribute. This ensures zeroization happens on all +exit paths, including error returns and early exits. For example:: + + static int my_aesxts_setkey(..., const u8 *key, unsigned int len) + { + struct crypto_aes_ctx aes __cleanup(aes_zeroize_ctx); + ... + + /* Only half of the key data is cipher key */ + keylen =3D (len >> 1); + ret =3D aes_expandkey(&aes, key, keylen); + if (ret) + return ret; + + ... do something with the cipher key ... + + /* The other half is the tweak key */ + ret =3D aes_expandkey(&aes, (u8 *)(key + keylen), keylen); + if (ret) + return ret; /* <-- Could leak cipher key without __cleanu= p */ + + ... do something with the tweak key ... + + /* No need for memzero_explicit() at the end thanks to the __clean= up */ + return 0; + } + +Note that __cleanup() attributes should not be used in functions that use +"goto" statements. The benefit of cleanup helpers is the removal of "gotos= ", +and that "goto" statements can jump between scopes, so the expectation is +that usage of "goto" and cleanup helpers is never mixed in the same functi= on. + + +Automatic vs. manual zeroization +-------------------------------- + +Many ``..._final()`` functions in the crypto library automatically zeroize +their context before returning. When this is the case, the kernel-doc for= the +function documents it:: + + After finishing, this zeroizes @ctx. So the caller does not need to d= o it. + +In these cases, callers on simple code paths (where ``..._final()`` is alw= ays +reached) do not need to add __cleanup() or explicit zeroization. +However, __cleanup() is still recommended whenever there are error paths +that bypass ``..._final()``, as it ensures zeroization on all paths. + +For algorithms where ``..._final()`` does *not* zeroize the context (such = as +the SHAKE XOFs, where ``shake_squeeze()`` can be called multiple times), +callers must explicitly zeroize the context by calling the appropriate hel= per +or using __cleanup(), for example:: + + struct shake_ctx ctx __cleanup(shake_zeroize_ctx); + + shake256_init(&ctx); + shake_update(&ctx, data, data_len); + shake_squeeze(&ctx, out, out_len); + /* ctx is automatically zeroized at end of scope */ diff --git a/Documentation/crypto/libcrypto.rst b/Documentation/crypto/libc= rypto.rst index e911e05215979..9533c12caa79d 100644 --- a/Documentation/crypto/libcrypto.rst +++ b/Documentation/crypto/libcrypto.rst @@ -165,4 +165,5 @@ API documentation libcrypto-signature libcrypto-unauth-encryption libcrypto-utils + libcrypto-zeroization sha3 --=20 2.55.0