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

[Lee Jones <lee@kernel.org>]

Sorry for the delay.  It's been a busy few weeks.

> 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.

Agreed on both counts.

Since the PM bit in the Frame Control header is unauthenticated and
processed prior to decryption, an unauthenticated QoS Null frame can
still flip the AP's PS state anyway, so the AP-side change is best
treated as a spec-compliance cleanup.

You were also right to suspect the client-side TIM path in
ieee80211_rx_mgmt_beacon(), when (dynamic_ps_timeout == 0) (for instance,
when power-save is disabled on the client interface) and IEEE80211_CONF_PS
is not set, mac80211 currently ignores its AID bit in the TIM and never
sends a wake nullfunc frame to flush the AP's buffered frames.

If you're happy for me to do so, I'll send the following 2-patch v3 series:

 1. Symmetric PM-bit handling in ieee80211_rx_h_sta_process() (only
    consulting the PM bit on data and bufferable management frames, while
    waking sleeping stations on Auth / (Re)AssocReq as-per 9fef65443388).

 2. Sending a wake nullfunc in ieee80211_rx_mgmt_beacon() when the TIM
    indicates buffered unicast traffic while IEEE80211_CONF_PS is not set.

Does this help or hinder?  Your call.  If you decline, I'll go ahead and
close out our internal (Android) report as `Won't Fix` and move on to
something else.

Thanks.

-- 
Lee Jones