On Mon, 2023-12-25 at 14:00 +0300, Dmitry Antipov wrote: > I'm trying to investigate the following WARN_ONCE() observed at > https://syzkaller.appspot.com/bug?extid=fdc5123366fb9c3fdc6d: > > ------------[ cut here ]------------ > no supported rates for sta (null) (0xffffffff, band 1) in rate_mask 0x0 with flags 0x0 > WARNING: CPU: 1 PID: 2875 at net/mac80211/rate.c:379 __rate_control_send_low+0x6d9/0x800 net/mac80211/rate.c:379 > ... > > There is a (weird and completely unreadable) reproducer, the most recent one > https://syzkaller.appspot.com/text?tag=ReproC&x=10437de6e80000 matches 6.7.0-rc6. > IIUC it creates a kind of a virtual subnet of 'mac80211_hwsim' instances and then > enforces an attempt to setup an incorrect set of rates. Since I assume that > this WARN_ONCE() shouldn't happen, there might be some missing check for the > contents of rate-related fields of 'struct ieee80211_sub_if_data'. I've found > that this WARN_ONCE() may be avoided one step later by silently dropping the > (presumably invalid?) rate control packet in 'ieee80211_tx_h_rate_ctrl()', > i. e.: > > diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c > index ed4fdf655343..3ca1db6bb0fd 100644 > --- a/net/mac80211/tx.c > +++ b/net/mac80211/tx.c > @@ -703,6 +703,9 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx) > txrc.reported_rate.idx = -1; > txrc.rate_idx_mask = tx->sdata->rc_rateidx_mask[info->band]; > > + if (unlikely(txrc.rate_idx_mask == 0)) > + return TX_DROP; > + > if (tx->sdata->rc_has_mcs_mask[info->band]) > txrc.rate_idx_mcs_mask = > tx->sdata->rc_rateidx_mcs_mask[info->band]; > > but most likely this is wrong and should be handled in some another > way somewhere else. > Yeah. I'd say rate_mask 0 is the problem, but ... oh, right. I think the problem is that we apply the rate mask while scanning, that doesn't really make sense ... If you're making a connection on 2.4 GHz (band 0) then you need not have a rate mask set up for 5 GHz (band 1), and so it's probably 0 by default, but scanning will go on that band anyway ... I think it stands to reason that the rate mask really should only apply to the operation on the interface, not the scanning, which would probably fix that? johannes
