Re: [PATCH 3/6] net/tcp-ao: clear the aes_cmac_key when done

On 05/08/2026 23.02, Eric Biggers wrote:
> On Wed, Aug 05, 2026 at 04:36:06PM +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/ipv4/tcp_ao.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/tcp_ao.c b/net/ipv4/tcp_ao.c
>> index a56bb79e15e0e..12c724fed8a26 100644
>> --- a/net/ipv4/tcp_ao.c
>> +++ b/net/ipv4/tcp_ao.c
>> @@ -141,7 +141,7 @@ void tcp_ao_calc_traffic_key(const struct tcp_ao_key *mkt, u8 *traffic_key,
>>   					traffic_key);
>>   		return;
>>   	case TCP_AO_ALGO_AES_128_CMAC: {
>> -		struct aes_cmac_key k;
>> +		struct aes_cmac_key k __cleanup(aes_cmac_zeroize_key);
>>   
>>   		aes_cmac_preparekey(&k, mkt->key, AES_KEYSIZE_128);
>>   		aes_cmac(&k, input, input_len, traffic_key);
> 
> Similar to the bluetooth patch: This is okay, but it seems the TCP-AO
> code has never really tried to do key zeroization, which is why I didn't
> include a memzero_explicit() here.  Lots of cases, like the various
> traffic key buffers, have never been zeroized and still aren't.
> 
> The '__cleanup' trick makes this specific case trivial enough that sure,
> it might as well be done anyway.  But it would be nice to have a more
> comprehensive patch that actually tried to zeroize all TCP-AO keys.
> Otherwise random individual fixes like this trickle in over time and it
> takes a lot longer.
Ok, I'll put this on my TODO list and will send a separate patch - for this 
series here, I'd prefer to limit it to aes_cmac_key / aes_cmac_ctx.

  Thomas