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

[Lee Jones]

On Mon, 28 Sep 2026, Johannes Berg wrote:

> On Mon, 2026-09-28 at 10:05 +0000, Lee Jones wrote:
> > Per IEEE 802.11, the Power Management subfield in the Frame Control
> > field is reserved in non-bufferable management frames (such as
> > Authentication, Association Request, and Reassociation Request) and a
> > station remains in Active mode during authentication and association.
> > 
> > When commit 9fef65443388 ("mac80211: always update the PM state of a
> > peer on MGMT / DATA frames") allowed non-bufferable management frames
> > to update peer power-save state so that re-authenticating stations
> > could transition from doze to awake (sta_ps_end()), it also allowed
> > non-bufferable management frames with the Power Management bit set to
> > transition an awake station into power-save mode (sta_ps_start()).
> > 
> > Restrict wake-to-doze transitions (sta_ps_start()) in
> > ieee80211_rx_h_sta_process() to data, action, disassociation, and
> > deauthentication frames using hdr->frame_control (avoiding inspecting
> > encrypted action frame payloads prior to ieee80211_rx_h_decrypt()) while
> > preserving doze-to-wake transitions (sta_ps_end()).
> > 
> 
> This doesn't make sense to me - you don't really say why you're making
> this change other than saying what the spec says, but then you're
> explicitly not spec compliant both ways - without any explanation either
> way?

Fair point, sorry for that.

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.

Plans for v2 with your blessing:

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


-- 
Lee Jones