From: Lee Jones <lee@kernel.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
Luca Coelho <luciano.coelho@intel.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] wifi: mac80211: ignore PM bit in non-bufferable MMPDUs for PS start
Date: Mon, 28 Sep 2026 15:24:34 +0100 [thread overview]
Message-ID: <20260928142434.GA2112133@google.com> (raw)
In-Reply-To: <9b3efaebb9f5460f6bfaaa284fd235e76c940361.camel@sipsolutions.net>
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
prev parent reply other threads:[~2026-09-28 14:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 10:05 Lee Jones
2026-09-28 10:15 ` Johannes Berg
2026-09-28 14:24 ` Lee Jones [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=20260928142434.GA2112133@google.com \
--to=lee@kernel.org \
--cc=emmanuel.grumbach@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luciano.coelho@intel.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
all inboxes | Powered by JetHome®