[PATCH] wifi: mac80211: reject station association if AP is not started

[PATCH] wifi: mac80211: reject station association if AP is not started

[syzbot]

From: Slawomir Stepien <sst@poczta.fm>

If an interface is changed to AP mode but not started, its channel context
configuration (chanctx_conf) remains NULL. If a station is then added to
this interface, the kernel may automatically set the
NL80211_STA_FLAG_ASSOCIATED flag for compatibility with older userspace
applications.

When this flag is set, sta_apply_auth_flags() attempts to initialize rate
control for the station by calling rate_control_rate_init_all_links(). This
eventually leads to rate_control_rate_init(), which dereferences the NULL
chanctx_conf, triggering a WARN_ON:

WARNING: net/mac80211/rate.c:51 at rate_control_rate_init+0x5a6/0x630
...
Call Trace:
 <TASK>
 rate_control_rate_init_all_links+0xf4/0x190 net/mac80211/rate.c:84
 sta_apply_auth_flags+0x1bc/0x430 net/mac80211/cfg.c:2152
 sta_apply_parameters+0x126d/0x1b10 net/mac80211/cfg.c:2618
 ieee80211_add_station+0x3de/0x700 net/mac80211/cfg.c:2684
 rdev_add_station+0xfc/0x290 net/wireless/rdev-ops.h:201
 nl80211_new_station+0x1b4e/0x1fd0 net/wireless/nl80211.c:9505

Fix this by rejecting the addition or modification of a station to the
associated state if the AP has not been started (chanctx_conf is NULL).
Exempt Multi-Link Operation (MLO) interfaces from this check, as they
handle chanctx_conf per-link rather than globally on the VIF.

Fixes: 55de908ab292 ("mac80211: use channel contexts")
Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+9bdc0c5998ab45b05030@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9bdc0c5998ab45b05030
Link: https://syzkaller.appspot.com/ai_job?id=64f3e3ae-e43e-4917-b403-f9b7799fe1bc
Signed-off-by: Slawomir Stepien <sst@poczta.fm>

---
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3b58af59f..830c9fc95 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2148,8 +2148,13 @@ static int sta_apply_auth_flags(struct ieee80211_local *local,
 		 * well. Some drivers require rate control initialized
 		 * before drv_sta_state() is called.
 		 */
-		if (!test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
+		if (!test_sta_flag(sta, WLAN_STA_RATE_CONTROL)) {
+			if (!ieee80211_vif_is_mld(&sta->sdata->vif) &&
+			    !rcu_access_pointer(sta->sdata->vif.bss_conf.chanctx_conf))
+				return -EINVAL;
+
 			rate_control_rate_init_all_links(sta);
+		}
 
 		ret = sta_info_move_state(sta, IEEE80211_STA_ASSOC);
 		if (ret)


base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
-- 
See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
You can comment on the patch as usual, syzbot will try to address
the comments and send a new version of the patch if necessary.
syzbot engineers can be reached at syzkaller@googlegroups.com.

Re: [PATCH] wifi: mac80211: reject station association if AP is not started

[Johannes Berg]

On Thu, 2026-07-23 at 08:11 +0000, syzbot wrote:
> From: Slawomir Stepien <sst@poczta.fm>

I'm a bit confused? Did syzbot just pick up another patch?

> dereferences the NULL chanctx_conf, triggering a WARN_ON:

That can't be right?

> Fix this by rejecting the addition or modification of a station to the
> associated state if the AP has not been started (chanctx_conf is NULL).

That's a proxy for "AP is started", but not a good one, I think we
actually have a flag or so somewhere? Maybe even reject it in cfg80211?

> Exempt Multi-Link Operation (MLO) interfaces from this check, as they
> handle chanctx_conf per-link rather than globally on the VIF.

Feels like that's only necessary because the proxy is bad.

Also maybe a similar issue arises if an MLO AP is only half-started, and
stations are added to all links, or so?

johannes

Re: [PATCH] wifi: mac80211: reject station association if AP is not started

[Slawomir Stepien]

On lip 23, 2026 11:14, Johannes Berg wrote:
> On Thu, 2026-07-23 at 08:11 +0000, syzbot wrote:
> > From: Slawomir Stepien <sst@poczta.fm>
> 
> I'm a bit confused? Did syzbot just pick up another patch?

Hi Johannes!

No, this issue has been found by syzbot while doing fuzzing testing.

> > dereferences the NULL chanctx_conf, triggering a WARN_ON:
> 
> That can't be right?

Yeah, right. I will rephrase it in v2.

> > Fix this by rejecting the addition or modification of a station to the
> > associated state if the AP has not been started (chanctx_conf is NULL).
> 
> That's a proxy for "AP is started", but not a good one, I think we
> actually have a flag or so somewhere? Maybe even reject it in cfg80211?

I haven't seen a good place for rejection, but let me double check.

> > Exempt Multi-Link Operation (MLO) interfaces from this check, as they
> > handle chanctx_conf per-link rather than globally on the VIF.
> 
> Feels like that's only necessary because the proxy is bad.
> 
> Also maybe a similar issue arises if an MLO AP is only half-started, and
> stations are added to all links, or so?

Not sure about MLO, but your suggestion sounds logical and such case might be the same as this one.
I will take a look at this too.

-- 
Slawomir Stepien

Re: [PATCH] wifi: mac80211: reject station association if AP is not started

[Johannes Berg]

On Fri, 2026-07-24 at 08:50 +0200, Slawomir Stepien wrote:
> On lip 23, 2026 11:14, Johannes Berg wrote:
> > On Thu, 2026-07-23 at 08:11 +0000, syzbot wrote:
> > > From: Slawomir Stepien <sst@poczta.fm>
> > 
> > I'm a bit confused? Did syzbot just pick up another patch?
> 
> Hi Johannes!
> 
> No, this issue has been found by syzbot while doing fuzzing testing.

Yeah, but the email? It's "From: syzbot <...>" and actually was
delivered to me by sea.source.kernel.org, whereas your other mail was
delivered to me by smtpo49.interia.pl, so I'm confused as to who sent
the mail and how :)

johannes

Re: [PATCH] wifi: mac80211: reject station association if AP is not started

[Slawomir Stepien]

On lip 24, 2026 09:15, Johannes Berg wrote:
> On Fri, 2026-07-24 at 08:50 +0200, Slawomir Stepien wrote:
> > On lip 23, 2026 11:14, Johannes Berg wrote:
> > > On Thu, 2026-07-23 at 08:11 +0000, syzbot wrote:
> > > > From: Slawomir Stepien <sst@poczta.fm>
> > > 
> > > I'm a bit confused? Did syzbot just pick up another patch?
> > 
> > Hi Johannes!
> > 
> > No, this issue has been found by syzbot while doing fuzzing testing.
> 
> Yeah, but the email? It's "From: syzbot <...>" and actually was
> delivered to me by sea.source.kernel.org, whereas your other mail was
> delivered to me by smtpo49.interia.pl, so I'm confused as to who sent
> the mail and how :)

The initial e-mail with patch was sent by the syzbot on my request, that's why I'm in the added From
and Signed-off-by (bot can't be the Author of commit and I'm responsible for handling this patch on
mailing list).

You can read more about this here:
https://github.com/google/syzkaller/blob/master/docs/syzbot_ai_patches.md.

-- 
Slawomir Stepien