From: Johannes Berg <johannes@sipsolutions.net>
To: Eric Biggers <ebiggers@kernel.org>,
linux-wireless@vger.kernel.org,
Jouni Malinen <jouni.malinen@oss.qualcomm.com>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] wifi: mac80211: Fix cryptographic MAC comparison to be constant-time
Date: Thu, 09 Jul 2026 08:45:35 +0200 [thread overview]
Message-ID: <3e8e6ff58a0809b0346d133c01eda720367eb511.camel@sipsolutions.net> (raw)
In-Reply-To: <20260709024443.58132-1-ebiggers@kernel.org>
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@vger.kernel.org
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@kernel.org/
(The whole feature is also fairly much unused anyway in practice as far
as I can tell.)
johannes
next prev parent reply other threads:[~2026-07-09 6:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 2:44 [PATCH] wifi: mac80211: Fix cryptographic MAC comparison to be constant-time Eric Biggers
2026-07-09 6:45 ` Johannes Berg [this message]
2026-07-09 15:20 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e8e6ff58a0809b0346d133c01eda720367eb511.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ebiggers@kernel.org \
--cc=jouni.malinen@oss.qualcomm.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox