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

[Johannes Berg]

On Wed, 2026-07-08 at 22:44 -0400, 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@xxxxxxxxxxxxxxx

I guess I'll apply (a variant of) this patch for -next, but that commit
log really makes it sound like something is actually broken and needs
fixing, and I don't think that's true in this specific context.

What happens is that the frame is validated and then we associate
successfully (upon success) or drop the frame (upon failure). Only the
failure case is relevant for the timing issue, but in that case we
simply drop the frame and there isn't really an observable signal -
nothing else happens, at least not immediately, we may retry the request
later after a timer.

So sure, it looks better to have a crypto_memneq() in AES-SIV related
code, but in practice I don't see how it would make a difference now,
and it's even unlikely this code will ever matter for anything else in
the future, given that things are moving more and more towards full
frame encryption, including association request/response now.

I saw you originally had this in the "use libraries" patch [1], I'm also
good with you just keeping the change there. This might even be better
if you're planning to have this in -next soon, where it would otherwise
conflict if I keep this to -next.

[1] https://lore.kernel.org/linux-crypto/20260707053503.209874-24-ebiggers@xxxxxxxxxx/

(The whole feature is also fairly much unused anyway in practice as far
as I can tell.)

johannes