Re: [PATCH] wifi: mac80211: defer AP-side FT key upload until association

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2026-07-30 at 18:14 +0200, andcov23@gmail.com wrote:
> From: Andrea Covelli <andcov23@gmail.com>
> 
> During an AP-side Fast Transition, hostapd may install the PTK after
> creating a station entry but before marking it associated. The ASSOC gate
> in ieee80211_add_key() rejects the request with -ENOENT, producing:
> 
>   nl80211: kernel reports: key addition failed
> 
> Userspace may retry after association, but this race can instead break
> the roam, particularly with PMF.
> 
> Accept pre-association pairwise keys on AP and AP_VLAN interfaces once
> the station exists. Mark only those keys as deferred so hardware upload
> is skipped while the key is stored in mac80211. Upload the marked PTKs
> after the driver's AUTH-to-ASSOC state transition succeeds.
> 
> Track deferred state on each key and scan the station's PTK slots at
> ASSOC so hardware upload is limited to keys accepted before association.
> EPP peers are excluded from this deferral because EPP requires the PTK
> to be available before association to encrypt and decrypt
> (Re)Association Request and Response frames.
> 
> Fixes: 1626e0fa740d ("mac80211: fix FT roaming")

This is _ages_ ago, so this bug has been around basically forever.

> Cc: stable@vger.kernel.org

I don't think the stable thing is appropriate then.

I also have a very large set of changes in this area that actually end
up doing something very similar for SMD Transition, and much more
comprehensively, which I'm about to post, so I think it's better for
this to be integrated with that work later.

This also doesn't consider the case of failure on HW support, i.e. with
SW_CRYPTO_CONTROL it just (without any comment I might add) skips the
thing by pretending the driver said it was OK. Not convinced that's a
good idea, although this might be something that can't really solved
better, perhaps.

johannes