mac80211_hwsim_sta_rc_update() compares ieee80211_sta_rx_bandwidth against 
the current channel context width. 

The STA bandwidth enum has no sub-20 MHz states, so a normal 20 MHz link 
STA falsely trips the warning on 5/10 MHz OCB channel contexts.so 
a normal 20 MHz link STA falsely trips the warning on 5/10 MHz OCB 
channel contexts.

Treat sub-20 MHz channel contexts as 20 MHz for this validation and use 
the actual channel-context width in the warning message.

Fixes: aea9a6088ae46 ("wifi: mac80211_hwsim: do rc update per link")
Reported-by: syzbot+c0472dd80bb8f668625f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c0472dd80bb8f668625f
Signed-off-by: meihaipeng <meihaipeng@uniontech.com>
---
 drivers/net/wireless/virtual/mac80211_hwsim.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index 1fcf5d0d2e13..3d759fb328a8 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -2793,6 +2793,7 @@ mac80211_hwsim_sta_rc_update(struct ieee80211_hw *hw,
 	for (link_id = 0;
 	     link_id < ARRAY_SIZE(vif->link_conf);
 	     link_id++) {
+		u32 confbw_mhz = 20;
 		enum nl80211_chan_width confbw = NL80211_CHAN_WIDTH_20_NOHT;
 		struct ieee80211_bss_conf *vif_conf;
 
@@ -2826,10 +2827,17 @@ mac80211_hwsim_sta_rc_update(struct ieee80211_hw *hw,
 				confbw = chanctx_conf->def.width;
 		}
 
-		WARN(bw > hwsim_get_chanwidth(confbw),
+		/*
+		 * ieee80211_sta_rx_bandwidth does not represent sub-20 MHz
+		 * channels, so treat 5/10 MHz channel contexts as 20 MHz when
+		 * validating the link bandwidth.
+		 */
+		confbw_mhz = max_t(u32, confbw_mhz, hwsim_get_chanwidth(confbw));
+
+		WARN(bw > confbw_mhz,
 		     "intf %pM [link=%d]: bad STA %pM bandwidth %d MHz (%d) > channel config %d MHz (%d)\n",
 		     vif->addr, link_id, sta->addr, bw, sta->deflink.bandwidth,
-		     hwsim_get_chanwidth(data->bw), data->bw);
+		     hwsim_get_chanwidth(confbw), confbw);
 
 
 	}
-- 
2.20.1

Hi,

> The STA bandwidth enum has no sub-20 MHz states, so a normal 20 MHz link 
> STA falsely trips the warning on 5/10 MHz OCB channel contexts.so 
> a normal 20 MHz link STA falsely trips the warning on 5/10 MHz OCB 
> channel contexts.

There is also S1G widths :) but that doesn't really matter.

> Treat sub-20 MHz channel contexts as 20 MHz for this validation and use 
> the actual channel-context width in the warning message.
> 
> Fixes: aea9a6088ae46 ("wifi: mac80211_hwsim: do rc update per link")
> Reported-by: syzbot+c0472dd80bb8f668625f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=c0472dd80bb8f668625f
> Signed-off-by: meihaipeng <meihaipeng@uniontech.com>

Looking at the stack trace of this report and a few of the others,
it comes from mac80211_hwsim_sta_add() which calls the rc_update on
the new STA, so it would probably be better to do something similar
to what we did for S1G [1] since I'm pretty sure the rc_update()
path isn't reachable on 5/10MHz (just like S1G).

Though there are also quite a few 5/10MHz syzbot reports for various
things similar so maybe it's not worth it.. but that is up to
Johannes :).

[1] https://lore.kernel.org/linux-wireless/20260527033828.183821-2-lachlan.hodges@morsemicro.com/

lachlan

On Fri, 2026-05-29 at 15:10 +1000, Lachlan Hodges wrote:
> Hi,
> 
> > The STA bandwidth enum has no sub-20 MHz states, so a normal 20 MHz link 
> > STA falsely trips the warning on 5/10 MHz OCB channel contexts.so 
> > a normal 20 MHz link STA falsely trips the warning on 5/10 MHz OCB 
> > channel contexts.
> 
> There is also S1G widths :) but that doesn't really matter.
> 
> > Treat sub-20 MHz channel contexts as 20 MHz for this validation and use 
> > the actual channel-context width in the warning message.
> > 
> > Fixes: aea9a6088ae46 ("wifi: mac80211_hwsim: do rc update per link")
> > Reported-by: syzbot+c0472dd80bb8f668625f@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=c0472dd80bb8f668625f
> > Signed-off-by: meihaipeng <meihaipeng@uniontech.com>
> 
> Looking at the stack trace of this report and a few of the others,
> it comes from mac80211_hwsim_sta_add() which calls the rc_update on
> the new STA, so it would probably be better to do something similar
> to what we did for S1G [1] since I'm pretty sure the rc_update()
> path isn't reachable on 5/10MHz (just like S1G).

I don't know if it is or isn't, but a simpler change like that would
indeed seem preferable.

> Though there are also quite a few 5/10MHz syzbot reports for various
> things similar so maybe it's not worth it.. but that is up to
> Johannes :).

Yeah, I'm still going to rip it out entirely soon.

johannes