From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C57A39A811; Wed, 7 Jan 2026 15:53:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767801216; cv=none; b=JvQyITFbxIP+zt0lS2bttKwwMZw3EOi/3IUhyvyf9dSXesooTrveEUnovXqfwf0PH2Zlfpl/MJ/OZkk9prP+uYhVF/pOy2psDy8/cTopRQyyknDlL6pZA4xfK6zOZ1PCrC2PHPuknngDa7sisNx6Earrr4Yr7s2aM+60oWnDMao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767801216; c=relaxed/simple; bh=baIElWLGbbT3EEa9pR+TKV01vRMQoodNknv6twf9pyk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZzVv7SQx8ZlG3k+ZipJZVwpHRDUC2NV/Rb1dWrsgS1AjO2r6+FrXQTyQu7MV0KoN9DwKSazHppnz2H745DOt5yb3WwMDvyWl0nIqZZ7JY15ArazHsAvS28FCgJ365cDFcfUe77t6rVhVmlCtjMMmTGn3Vo8TJAd7IwTbuT8O6is= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PWJzcG55; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PWJzcG55" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6058C4CEF1; Wed, 7 Jan 2026 15:53:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767801215; bh=baIElWLGbbT3EEa9pR+TKV01vRMQoodNknv6twf9pyk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PWJzcG55gxymAqeMGzhVHpTRopNX3X2YBX7qVW9SFLnmkb+isaKQo8av+gwZhcFDe Qqrsp8Sa4+XGGpzMH6NkxRUwjFlE7duzs0Yaxa4YnuSk+mWtyRGU1I8tyulI/u4xXj bQZa4NwCKNS/HwjC7D2VvYeKLcNeHGCp/2QjI6gS08gdiuPDU81ihDpVVbNxgcNQ/D /2ItXEYUaLBZBh6C6vvhEkcjy6Ef5MpISrz84s2OJLcGTUQsNqcEN9Qja8L8lB/YGU VoxBL6NUJSqokstPZTkxXB61PfjcGCEKTbqi1d9DLnPE3CvXxFngcIzwicCFuZw9HR 2pycSkR+hIa8g== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Johannes Berg , syzbot+639af5aa411f2581ad38@syzkaller.appspotmail.com, Sasha Levin , johannes@sipsolutions.net, linux-wireless@vger.kernel.org Subject: [PATCH AUTOSEL 6.18] wifi: mac80211: don't WARN for connections on invalid channels Date: Wed, 7 Jan 2026 10:53:06 -0500 Message-ID: <20260107155329.4063936-4-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260107155329.4063936-1-sashal@kernel.org> References: <20260107155329.4063936-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-wireless@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Johannes Berg [ Upstream commit 99067b58a408a384d2a45c105eb3dce980a862ce ] It's not clear (to me) how exactly syzbot managed to hit this, but it seems conceivable that e.g. regulatory changed and has disabled a channel between scanning (channel is checked to be usable by cfg80211_get_ies_channel_number) and connecting on the channel later. With one scenario that isn't covered elsewhere described above, the warning isn't good, replace it with a (more informative) error message. Reported-by: syzbot+639af5aa411f2581ad38@syzkaller.appspotmail.com Link: https://patch.msgid.link/20251202102511.5a8fb5184fa3.I961ee41b8f10538a54b8565dbf03ec1696e80e03@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Analysis of Commit: wifi: mac80211: don't WARN for connections on invalid channels ### 1. COMMIT MESSAGE ANALYSIS **Subject:** Indicates removal of a WARN for a legitimate condition in WiFi channel handling. **Key details from message:** - **Reported by syzbot** - demonstrates this is a reproducible, real- world triggerable issue - **Author:** Johannes Berg - the mac80211 maintainer and highly trusted kernel developer - **Scenario explained:** Regulatory changes can disable a channel between scanning and connecting, making this condition legitimately reachable (not a kernel bug) - The WARN_ON was inappropriate because it treats a recoverable condition as a programming error ### 2. CODE CHANGE ANALYSIS The change is in `ieee80211_determine_chan_mode()` in `net/mac80211/mlme.c`: **Before:** ```c if (WARN_ON(chanreq->oper.width == NL80211_CHAN_WIDTH_20_NOHT)) { ret = -EINVAL; goto free; } ``` **After:** ```c if (chanreq->oper.width == NL80211_CHAN_WIDTH_20_NOHT) { link_id_info(sdata, link_id, "unusable channel (%d MHz) for connection\n", chanreq->oper.chan->center_freq); ret = -EINVAL; goto free; } ``` **Technical explanation:** - The loop tries to downgrade channel width when a channel is not usable - When it reaches minimum width (20MHz NOHT) and channel is still unusable, connection fails - **The bug:** `WARN_ON()` was used, but this condition CAN happen legitimately (e.g., regulatory DB change between scan and connect) - **The fix:** Replaces WARN_ON with an informative log message; same functional behavior (-EINVAL return) ### 3. CLASSIFICATION - **Type:** Bug fix - inappropriate WARN removal - **NOT a feature addition:** Same functional behavior, just better error handling - **Security-adjacent:** On systems with `panic_on_warn=1`, this could cause a kernel crash from a user-triggerable condition ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed:** ~5 lines net change - **Files touched:** 1 file - **Risk:** **VERY LOW** - Functional behavior unchanged (returns -EINVAL in same conditions) - Only changes logging output - Cannot introduce regression ### 5. USER IMPACT **Affected users:** - **panic_on_warn systems:** Could crash from this legitimate condition - HIGH impact - **All WiFi users:** Reduces log noise from false warnings - MEDIUM impact - **Production environments:** Many use panic_on_warn, making this important **Severity:** This is syzbot-triggerable, meaning attackers could potentially trigger crashes on panic_on_warn systems. ### 6. STABILITY INDICATORS - ✅ Reported-by: syzbot (confirmed reproducible) - ✅ Johannes Berg is the mac80211 maintainer - ✅ Fix is trivially correct - ✅ No complex logic changes ### 7. DEPENDENCY CHECK - **Standalone fix:** No dependencies on other commits - **Code path existence:** `ieee80211_determine_chan_mode()` is core mac80211 code that exists in stable trees ### STABLE KERNEL CRITERIA EVALUATION | Criterion | Met? | Notes | |-----------|------|-------| | Obviously correct | ✅ | Simple WARN_ON removal | | Fixes real bug | ✅ | syzbot reported, crashes on panic_on_warn | | Important issue | ✅ | Potential crashes in production | | Small and contained | ✅ | ~5 lines, 1 file | | No new features | ✅ | Same behavior, better logging | | Applies cleanly | ✅ | Standard pattern | ### RISK VS BENEFIT **Benefits:** - Prevents crashes on panic_on_warn systems - Fixes syzbot-reported issue - Provides better diagnostic information - Zero functional change to normal operation **Risks:** - Essentially none - the change is purely about removing an inappropriate warning and adding informational logging ### CONCLUSION This is a textbook example of a good stable backport candidate: 1. Small, surgical fix (few lines, one file) 2. Fixes a real bug that syzbot can trigger 3. From the subsystem maintainer 4. Zero risk of regression (same functional behavior) 5. Important for panic_on_warn systems which are common in production The fix correctly recognizes that a channel becoming unusable between scan and connect is a legitimate condition (e.g., due to regulatory changes), not a kernel bug that warrants WARN_ON. **YES** net/mac80211/mlme.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index f3138d158535..c8b588f4e494 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -1126,7 +1126,10 @@ ieee80211_determine_chan_mode(struct ieee80211_sub_if_data *sdata, while (!ieee80211_chandef_usable(sdata, &chanreq->oper, IEEE80211_CHAN_DISABLED)) { - if (WARN_ON(chanreq->oper.width == NL80211_CHAN_WIDTH_20_NOHT)) { + if (chanreq->oper.width == NL80211_CHAN_WIDTH_20_NOHT) { + link_id_info(sdata, link_id, + "unusable channel (%d MHz) for connection\n", + chanreq->oper.chan->center_freq); ret = -EINVAL; goto free; } -- 2.51.0