Re: [PATCH 1/1] wifi: mac80211: ignore PM bit in non-bufferable MMPDUs for PS start

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2026-09-28 at 15:24 +0100, Lee Jones wrote:
> 
> The commit message was purposely vague due to the fact that the change
> fixes a security issue and I didn't want to publish a HOWTO guide for
> exploiting it.  However, I obviously overdid it a little and left out
> the reasoning you'd need to review the patch.  The short version is that
> an unauthenticated peer can currently change an associated station's
> power save state with frames that shouldn't be able to have that
> capability which can be used against the station.
> 
> Happy to send you the details off-list.

I think I've (conceptually) known about this issue for ... years?

First, arguably wake-to-doze are _less_ interesting to attack, since
then the TIM bit will end up getting set and if the STA isn't sleeping
it'll see the beacon and recover fairly easily (though not entirely sure
we actually implement that in mac80211), and if it keeps sending traffic
then the state corruption is short-lived.
OTOH, corrupting doze-to-wake could lead to traffic getting dropped if
TX filtering status isn't implemented well on the AP side/driver since
the STA is actually sleeping and won't see any frames.

Second, I don't think in general this issue is fixable, and while it's
good to implement this closer to the spec, security wise it doesn't
really do anything as is?

If, for example, there's any bufferable MMPDU the attacker can just
replay it - we've been doing this before MIC/replay check forever
(unless that's offloaded). It can also - although this is harder -
intercept and modify the PM bit, since it's not protected by the AAD.

It's also wrong that we're doing this *after* the reorder buffer, since
that potentially holds the frames for a long time, and the spec says to
look at the PM bit after the frame exchange sequence completes (REVmf
11.2.3.2). We should fix that too, but it doesn't really matter for this
discussion:

Any unprotected complete frame exchange sequence can modify the state
anyway, QoS NDP for example.

>  - Rewrite the commit message to explain the problem and the reasoning
>    properly, rather than just quoting the spec.
> 
>  - Make the PM handling consistent in both directions, so it doesn't
>    honour the bit in one case and ignore it in the other, while keeping
>    the re-authenticating station case from 9fef65443388 working.
> 
> Does that work for you?

Well, I think it's really only a spec compliance cleanup, but then we
might as well try to fix some of the other issues?

I also think we might be better off making sure that as a client we
handle the TIM indicating traffic while awake and send a wake frame, and
perhaps checking AP side handles filtered/un-acked traffic well.

johannes