Received-SPF: pass (google.com: domain of linux-wireless+bounces-1280-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <dbe8a8334edc56e2488bacaeccf8474a79faae0f.camel@sipsolutions.net>
Subject: Re: mac80211: WARN_ONCE("no supported rates for sta ...")
From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: linux-wireless@vger.kernel.org
Date: Mon, 25 Dec 2023 14:40:54 +0100
In-Reply-To: <92f0017d-7b1d-4562-984f-885179b50435@yandex.ru>
References: <92f0017d-7b1d-4562-984f-885179b50435@yandex.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

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=3Dfdc5123366fb9c3fdc6d:
>=20
> ------------[ cut here ]------------
> no supported rates for sta (null) (0xffffffff, band 1) in rate_mask 0x0 w=
ith flags 0x0
> WARNING: CPU: 1 PID: 2875 at net/mac80211/rate.c:379 __rate_control_send_=
low+0x6d9/0x800 net/mac80211/rate.c:379
> ...
>=20
> There is a (weird and completely unreadable) reproducer, the most recent =
one
> https://syzkaller.appspot.com/text?tag=3DReproC&x=3D10437de6e80000 matche=
s 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 th=
at
> 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 f=
ound
> 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.:
>=20
> 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 =3D -1;
>          txrc.rate_idx_mask =3D tx->sdata->rc_rateidx_mask[info->band];
>=20
> +       if (unlikely(txrc.rate_idx_mask =3D=3D 0))
> +               return TX_DROP;
> +
>          if (tx->sdata->rc_has_mcs_mask[info->band])
>                  txrc.rate_idx_mcs_mask =3D
>                          tx->sdata->rc_rateidx_mcs_mask[info->band];
>=20
> but most likely this is wrong and should be handled in some another
> way somewhere else.
>=20

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