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