Re: [PATCH 0/8] wifi: fix PMSR lifetime and frame validation issues

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2026-07-09 at 03:59 +0800, Zhao Li wrote:
> Hi,
> 
> This series fixes a set of PMSR lifetime and management-frame
> validation issues found while reviewing the wireless stack.

This is honestly a bit messy as a series, covering all kinds of drivers
and CC'ing everyone. It'd be a lot simpler for everyone if you just sent
them all individually, or at least per subsystem, putting only the ones
that depend on each other together.

> Zhao Li (8):
>   wifi: mac80211_hwsim: clear PMSR request state on abort
>   wifi: mac80211_hwsim: authenticate PMSR report senders

I'm going to look at these only for wireless-next later, I don't think
hwsim is all that relevant in deployed systems.

>   wifi: iwlwifi: mld: abort active PMSR requests

I don't know about this, Miri should look (I think she said it was
handled already or so in patchwork).

>   wifi: cfg80211: guard optional PMSR nominal time

That one vaguely seems like I should apply it now.

>   wifi: mac80211: validate probe response countdown offsets

I think this one is falling into a typical LLM pattern patching trap, it
describes [0] as being out-of-bounds for some allocated data, and
neglects that the offsets have already been checked by cfg80211. Please
describe more why it's actually an issue beyond "there's a similar
pattern elsewhere".

>   wifi: mac80211: validate S1G TWT params before driver setup

I don't know about this, you should probably resend it. Anyway I'm not
loosing sleep over it since there's no driver with the callback, tracing
is mostly not enabled, and while a potential 12 bytes OOB read at the
end of the SKB is a bug, it's not a very important one since there
should be stuff there anyway.

>   wifi: mwifiex: validate action frame fixed fields

Francesco should look at that - again, sending it all together makes
this really hard - but it seems to me it should use MIN_ACTION_SIZE()?

>   wifi: nl80211: clean up color-change beacon data on errors

In this one it seems it'd be much simpler to allocate the memory first,
i.e. change the order of operations rather than complicate the cleanup?

johannes