[PATCH RESEND] wifi: mac80211: Fix cryptographic MAC comparison to be constant-time

[PATCH RESEND] wifi: mac80211: Fix cryptographic MAC comparison to be constant-time

[Eric Biggers]

To prevent timing attacks, the comparison of cryptographic message
authentication codes (MACs) needs to have data-independent timing.
Replace the memcmp() with the correct function, crypto_memneq().

Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
 net/mac80211/fils_aead.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/fils_aead.c b/net/mac80211/fils_aead.c
index 9c4f00d61981d..638ced7685af6 100644
--- a/net/mac80211/fils_aead.c
+++ b/net/mac80211/fils_aead.c
@@ -202,7 +202,7 @@ static int aes_siv_decrypt(const u8 *key, size_t key_len,
 	res = aes_s2v(key /* K1 */, key_len, num_elem, addr, len, check);
 	if (res)
 		return res;
-	if (memcmp(check, frame_iv, AES_BLOCK_SIZE) != 0)
+	if (crypto_memneq(check, frame_iv, AES_BLOCK_SIZE))
 		return -EINVAL;
 	return 0;
 }

base-commit: 21a7f44fd0765fcc5194130b28767786eba1d1e7
-- 
2.56.0

Re: [PATCH RESEND] wifi: mac80211: Fix cryptographic MAC comparison to be constant-time

[Johannes Berg]

On Sun, 2026-10-25 at 14:00 -0700, Eric Biggers wrote:
> To prevent timing attacks, the comparison of cryptographic message
> authentication codes (MACs) needs to have data-independent timing.
> Replace the memcmp() with the correct function, crypto_memneq().
> 
> Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
> Cc: stable@vger.kernel.org
> 

I'll apply this if you either come up with an actual attack, or stop
pretending it's a bug.

johannes

Re: [PATCH RESEND] wifi: mac80211: Fix cryptographic MAC comparison to be constant-time

[Eric Biggers]

On Sun, Oct 25, 2026 at 10:37:47PM +0100, Johannes Berg wrote:
> On Sun, 2026-10-25 at 14:00 -0700, Eric Biggers wrote:
> > To prevent timing attacks, the comparison of cryptographic message
> > authentication codes (MACs) needs to have data-independent timing.
> > Replace the memcmp() with the correct function, crypto_memneq().
> > 
> > Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
> > Cc: stable@vger.kernel.org
> > 
> 
> I'll apply this if you either come up with an actual attack, or stop
> pretending it's a bug.

I don't have time to set up a system using IEEE 802.11ai and try to
exploit this to forge a frame, sorry.  Especially when we fix timing
bugs like this all the time.  Realistically, these types of bugs are
usually hard to exploit (e.g., involving sending a lot of packets and
doing statistical analysis) and can be the topic of a research paper.
But that doesn't mean they don't exist or aren't obvious bugs.

You can find more details about such bugs at external sources such as
https://blog.canutethegreat.com/index.php/2026/10/04/timing-side-channels-constant-time-comparison/
A memcmp of HMAC values (16 bytes, which coincidentally is the same
length here) was also exploited in the Xbox 360 to install arbitrary
code.  That example is covered in cryptography textbooks.

The use of AES-SIV here does seem to remove some flexibility for the
attacker over a MAC by itself, due to the synthetic IV.  But that gets
defeated by frames with zero-length ciphertexts, as far as I can tell,
which can still include arbitrary IEs as associated data in addr[4].

Understood that you don't want to fix this bug now, though you've
accepted similar fixes in the past such as 98c67d187db7.  It will still
need to be fixed at some point anyway unless this code is dropped.
Perhaps you could consider at least applying it without the tags for
now, and we can consider the stable backport separately later.

- Eric