From: Eric Biggers <ebiggers@kernel.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, linux-crypto@vger.kernel.org,
Yuqi Xu <xuyuqiabc@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH RESEND] wifi: mac80211: Fix cryptographic MAC comparison to be constant-time
Date: Sun, 25 Oct 2026 16:27:46 -0700 [thread overview]
Message-ID: <20261025232746.GB148998@quark> (raw)
In-Reply-To: <676effaff715929da980158820833c18a3a2845c.camel@sipsolutions.net>
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
prev parent reply other threads:[~2026-10-25 23:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 21:00 [PATCH RESEND] wifi: mac80211: Fix cryptographic MAC comparison to be constant-time Eric Biggers
2026-10-25 21:37 ` Johannes Berg
2026-10-25 23:27 ` Eric Biggers [this message]
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=20261025232746.GB148998@quark \
--to=ebiggers@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=xuyuqiabc@gmail.com \
/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