Re: [PATCH 4/6] Bluetooth: SMP: clear the aes_cmac_key when done

Thomas Huth <[email protected]>
Newsgroups org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-crypto,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 05/08/2026 22.46, Eric Biggers wrote:
> On Wed, Aug 05, 2026 at 04:36:07PM +0200, Thomas Huth wrote:
>> From: Thomas Huth <[email protected]>
>>
>> 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 <[email protected]>
>> ---
>>   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.)
Sure, I can add a line to clear tmp[] here, too.

And I agree, there are other spots in this file that likely need fixing, 
e.g. smp_e() already clears struct aes_enckey aes, but misses to zeroize its 
tmp[] array, too, that again contains key material, I think?

But I think I'll rather tackle those in a separate patch series, since this 
series here is clearly aimed at aes_cmac_key & aes_cmac_ctx.

  Thomas
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.