Re: [PATCH 4/6] Bluetooth: SMP: clear the aes_cmac_key when done
From: Eric Biggers
Date: Wed Aug 05 2026 - 16:46:24 EST
On Wed, Aug 05, 2026 at 04:36:07PM +0200, Thomas Huth wrote:
> From: Thomas Huth <thuth@xxxxxxxxxx>
>
> Clear the local aes_cmac_key structure via __cleanup() function
> when we're done with it to avoid that sensitive data could leak on
> the stack.
>
> Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx>
> ---
> net/bluetooth/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index 031d3022cb1e5..ed30ca0d773f1 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -164,7 +164,7 @@ static inline void swap_buf(const u8 *src, u8 *dst, size_t len)
> static int smp_aes_cmac(const u8 k[16], const u8 *m, size_t len, u8 mac[16])
> {
> uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
> - struct aes_cmac_key key;
> + struct aes_cmac_key key __cleanup(aes_cmac_zeroize_key);
> int err;
>
> if (len > CMAC_MSG_MAX)
Well, the reason I didn't add a memzero_explicit() here when converting
the code to use the AES-CMAC library is because this same function
already puts the raw key on the stack without zeroizing it.
I guess the __cleanup trick makes zeroizing the struct trivial enough
that we should just do it anyway. But it is always a bit awkward to be
"fixing" something when the same problem is still present.
Perhaps you'd like to expand this patch a bit to zeroize the other data
too? (There is the 'tmp' array in this same function of course, but
there may be other places that need "fixing" too.)
- Eric