[PATCH v2] mac80211: reject station addition if AP or MLO link is inactive

[PATCH v2] mac80211: reject station addition if AP or MLO link is inactive

[Slawomir Stepien]

Currently, userspace can issue a netlink command to add a station to
an AP or P2P GO interface before the AP has fully started, or before
a specific MLO link has begun beaconing. This will e.g. lead to a
WARN_ON trigger:

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 introducing a two-tiered active state check in
ieee80211_add_station():

1. Global AP State: Add an early return if the main wdev is an AP or
   P2P GO and `sdata->u.ap.active` is false.

2. MLO Link State: For Wi-Fi 7 MLO setups, links can start asynchronously.
   Even if the global AP is active, a specific link might still be down.
   If a specific link_id is requested, ensure the underlying physical link
   has an allocated beacon (`link->u.ap.beacon`) before proceeding with
   sta_info allocation.

Assisted-by: Gemini:3.1-pro
Reported-by: syzbot+9bdc0c5998ab45b05030@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9bdc0c5998ab45b05030
Signed-off-by: Slawomir Stepien <sst@poczta.fm>
---
v2:
* Move the logic inside ieee80211_add_station()
* Check both the non-MLO AP/P2P state and MLO link state
* Update subject line and commit message

v1:
* https://lore.kernel.org/linux-wireless/373210a9-4365-4cac-823a-0eec391858e7@mail.kernel.org/
---
 net/mac80211/cfg.c | 43 ++++++++++++++++++++++++++++++++++---------
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 43f142624d33..c3a580ad97e9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2637,19 +2637,24 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct wireless_dev *wdev,
 {
 	struct ieee80211_local *local = wiphy_priv(wiphy);
 	struct sta_info *sta;
-	struct ieee80211_sub_if_data *sdata;
+	struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
 	int err;
 
 	lockdep_assert_wiphy(local->hw.wiphy);
 
+	if (sdata->vif.type == NL80211_IFTYPE_AP ||
+	    sdata->vif.type == NL80211_IFTYPE_P2P_GO) {
+		if (!sdata->u.ap.active)
+			return -ENETDOWN;
+	}
+
 	if (params->vlan) {
 		sdata = IEEE80211_DEV_TO_SUB_IF(params->vlan);
 
 		if (sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
 		    sdata->vif.type != NL80211_IFTYPE_AP)
 			return -EINVAL;
-	} else
-		sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
+	}
 
 	if (ether_addr_equal(mac, sdata->vif.addr))
 		return -EINVAL;
@@ -2663,17 +2668,37 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct wireless_dev *wdev,
 		return -EINVAL;
 
 	/*
-	 * If we have a link ID, it can be a non-MLO station on an AP MLD,
-	 * but we need to have a link_mac in that case as well, so use the
-	 * STA's MAC address in that case.
+	 * If we have a link ID:
+	 * (1) check if it is valid, up and beaconing
+	 * (2) it can be a non-MLO station on an AP MLD, but we need to have a
+	 * link_mac in that case as well, so use the STA's MAC address in that
+	 * case.
 	 */
-	if (params->link_sta_params.link_id >= 0)
+	if (params->link_sta_params.link_id >= 0) {
+		int link_id = params->link_sta_params.link_id;
+		struct ieee80211_link_data *link;
+		struct ieee80211_sub_if_data *wdev_sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
+
+		if (link_id >= IEEE80211_MLD_MAX_NUM_LINKS)
+			return -EINVAL;
+
+		link = sdata_dereference(wdev_sdata->link[link_id], wdev_sdata);
+		if (!link)
+			return -ENOLINK;
+
+		if (wdev_sdata->vif.type == NL80211_IFTYPE_AP ||
+		    wdev_sdata->vif.type == NL80211_IFTYPE_P2P_GO) {
+			if (!rcu_access_pointer(link->u.ap.beacon))
+				return -ENETDOWN;
+		}
+
 		sta = sta_info_alloc_with_link(sdata, mac,
-					       params->link_sta_params.link_id,
+					       link_id,
 					       params->link_sta_params.link_mac ?: mac,
 					       GFP_KERNEL);
-	else
+	} else {
 		sta = sta_info_alloc(sdata, mac, GFP_KERNEL);
+	}
 
 	if (!sta)
 		return -ENOMEM;
-- 
2.55.0

Re: [PATCH v2] mac80211: reject station addition if AP or MLO link is inactive

[Johannes Berg]

Hi,

On Mon, 2026-07-27 at 09:45 +0200, Slawomir Stepien wrote:
> Currently, userspace can issue a netlink command to add a station to
> an AP or P2P GO interface before the AP has fully started, or before
> a specific MLO link has begun beaconing. This will e.g. lead to a
> WARN_ON trigger:
> 
> 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 introducing a two-tiered active state check in
> ieee80211_add_station():

Shouldn't we have enough information in cfg80211 to validate it there,
benefiting other drivers?

johannes

Re: [PATCH v2] mac80211: reject station addition if AP or MLO link is inactive

[Slawomir Stepien]

On lip 27, 2026 10:19, Johannes Berg wrote:
> Hi,
> 
> On Mon, 2026-07-27 at 09:45 +0200, Slawomir Stepien wrote:
> > Currently, userspace can issue a netlink command to add a station to
> > an AP or P2P GO interface before the AP has fully started, or before
> > a specific MLO link has begun beaconing. This will e.g. lead to a
> > WARN_ON trigger:
> > 
> > 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 introducing a two-tiered active state check in
> > ieee80211_add_station():
> 
> Shouldn't we have enough information in cfg80211 to validate it there,
> benefiting other drivers?

I think we do not have. I'm looking at the struct wireless_dev fields and I see that there is just
info about what the configuration should be, not info about what is the current state of the device.
I also do not see any callback in struct cfg80211_ops that might help to get such info. If I'm wrong
then please correct my observation!

Beside this, do we think that all devices would always need this rejection? What if firmware of
these devices would benefit from *lack* of such rejection? Just thinking aloud, not that I know such
devices.

-- 
Slawomir Stepien

Re: [PATCH v2] mac80211: reject station addition if AP or MLO link is inactive

[Johannes Berg]

On Mon, 2026-07-27 at 11:22 +0200, Slawomir Stepien wrote:
> 
> I think we do not have. I'm looking at the struct wireless_dev fields and I see that there is just
> info about what the configuration should be, not info about what is the current state of the device.
> I also do not see any callback in struct cfg80211_ops that might help to get such info. If I'm wrong
> then please correct my observation!

I think we maintain wdev->links[].ap.beacon_interval?

> Beside this, do we think that all devices would always need this rejection? What if firmware of
> these devices would benefit from *lack* of such rejection? Just thinking aloud, not that I know such
> devices.

I don't think it should be legal in the userspace API, and even if they
did, we'd have to add a flag to let hostapd know about it, and then when
(probably never) we did that, we could change the checks along with the
API.

johannes

Re: [PATCH v2] mac80211: reject station addition if AP or MLO link is inactive

[Slawomir Stepien]

On lip 27, 2026 11:25, Johannes Berg wrote:
> On Mon, 2026-07-27 at 11:22 +0200, Slawomir Stepien wrote:
> > 
> > I think we do not have. I'm looking at the struct wireless_dev fields and I see that there is just
> > info about what the configuration should be, not info about what is the current state of the device.
> > I also do not see any callback in struct cfg80211_ops that might help to get such info. If I'm wrong
> > then please correct my observation!
> 
> I think we maintain wdev->links[].ap.beacon_interval?

Ah: https://elixir.bootlin.com/linux/v7.1.4/source/net/wireless/nl80211.c#L7188 and
https://elixir.bootlin.com/linux/v7.1.4/source/net/wireless/ap.c#L36. Ok! Let me try using that in
v3 then. Thanks!

> > Beside this, do we think that all devices would always need this rejection? What if firmware of
> > these devices would benefit from *lack* of such rejection? Just thinking aloud, not that I know such
> > devices.
> 
> I don't think it should be legal in the userspace API, and even if they
> did, we'd have to add a flag to let hostapd know about it, and then when
> (probably never) we did that, we could change the checks along with the
> API.

Sure. If you think it should be like that I can agree, since I do not have any opinion here.

-- 
Slawomir Stepien

Re: [PATCH v2] mac80211: reject station addition if AP or MLO link is inactive

[Slawomir Stepien]

On lip 27, 2026 12:26, Slawomir Stepien wrote:
> On lip 27, 2026 11:25, Johannes Berg wrote:
> > On Mon, 2026-07-27 at 11:22 +0200, Slawomir Stepien wrote:
> > > 
> > > I think we do not have. I'm looking at the struct wireless_dev fields and I see that there is just
> > > info about what the configuration should be, not info about what is the current state of the device.
> > > I also do not see any callback in struct cfg80211_ops that might help to get such info. If I'm wrong
> > > then please correct my observation!
> > 
> > I think we maintain wdev->links[].ap.beacon_interval?
> 
> Ah: https://elixir.bootlin.com/linux/v7.1.4/source/net/wireless/nl80211.c#L7188 and
> https://elixir.bootlin.com/linux/v7.1.4/source/net/wireless/ap.c#L36. Ok! Let me try using that in
> v3 then. Thanks!

After taking a closer look at this I wonder how AP_VLAN should be handled? Is there a way on
cfg80211 level to be able to check AP_VLAN's main device state?

My code change would look something like this:

@@ -9404,6 +9404,12 @@ static int nl80211_new_station(struct sk_buff *skb, struct genl_info *info)
        case NL80211_IFTYPE_AP:
        case NL80211_IFTYPE_AP_VLAN:
        case NL80211_IFTYPE_P2P_GO:
+               /* Add new station only after the AP and link has been started */
+               int link = params.link_sta_params.link_id >= 0 ?
+                          params.link_sta_params.link_id : 0;
+               if (!wdev->links[link].ap.beacon_interval)
+                       return -ENETDOWN;
+
                /* ignore WME attributes if iface/sta is not capable */
                if (!(rdev->wiphy.flags & WIPHY_FLAG_AP_UAPSD) ||
                    !(params.sta_flags_set & BIT(NL80211_STA_FLAG_WME)))

but the NL80211_IFTYPE_AP_VLAN case would not work here, right? Can I just do the checking only for
NL80211_IFTYPE_AP and NL80211_IFTYPE_P2P_GO and skip NL80211_IFTYPE_AP_VLAN?

-- 
Slawomir Stepien

[syzbot ci] Re: mac80211: reject station addition if AP or MLO link is inactive

[syzbot ci]

syzbot ci has tested the following series

[v2] mac80211: reject station addition if AP or MLO link is inactive
https://lore.kernel.org/all/20260727074526.248393-1-sst@poczta.fm
* [PATCH v2] mac80211: reject station addition if AP or MLO link is inactive

and found no issues.

Full report is available here:
https://ci.syzbot.org/series/92d73927-5773-4a58-89b9-a9d70926c88e

***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.