Received-SPF: pass (google.com: domain of linux-wireless+bounces-52-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <4ea5bf5ac1ddd64cfac7802b0c31822d71da7ebb.camel@sipsolutions.net>
Subject: Re: WARN_ON(!cbss) at net/mac80211/ibss.c:488
From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Antipov <dmantipov@yandex.ru>, "linux-wireless@vger.kernel.org"
	 <linux-wireless@vger.kernel.org>
Date: Fri, 24 Nov 2023 17:06:27 +0100
In-Reply-To: <1bd8f266-dee0-4d4e-9b50-e22546b55763@yandex.ru>
References: <1bd8f266-dee0-4d4e-9b50-e22546b55763@yandex.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
Precedence: bulk
MIME-Version: 1.0

On Fri, 2023-11-24 at 17:56 +0300, Dmitry Antipov wrote:
> I'm trying to investigate a WARN_ON() in subject, seen at least once
> with 5.10.200 under syzkaller. Surely this may be a weird artifact of
> using the syzkaller itself, but is there a scenario to trigger this
> WARN_ON() in a "real" environment? And, looking through the code, is
> it a good idea to call 'cfg80211_get_bss()' without checking whether
> the corresponding BSSID is non-zero?
>=20

I feel like we should probably just remove the WARN_ON()? Seems this is
either triggered by a strange CSA request from userspace, or a CSA
happening while also leaving the IBSS?

ieee80211_ibss_finish_csa() is strangely checking for
is_zero_ether_addr(), but I'm not sure how that happens when the state
is JOINED? Maybe there's somewhere a check missing that we cannot join
an IBSS with all-zeroes BSSID?

But I'm not sure how much value there is in digging deep into this ...

johannes