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

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

[Thomas Huth]

From: Thomas Huth <thuth@redhat.com>

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@redhat.com>
---
 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);
-- 
2.55.0

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

[Eric Biggers]

On Wed, Aug 05, 2026 at 04:36:06PM +0200, Thomas Huth wrote:
> From: Thomas Huth <thuth@redhat.com>
> 
> 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@redhat.com>
> ---
>  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.

- Eric

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

[Thomas Huth]

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 <thuth@redhat.com>
>>
>> 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@redhat.com>
>> ---
>>   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