patches.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Lachlan Hodges <lachlan.hodges@morsemicro.com>,
	Johannes Berg <johannes.berg@intel.com>,
	Sasha Levin <sashal@kernel.org>,
	johannes@sipsolutions.net, linux-wireless@vger.kernel.org
Subject: [PATCH AUTOSEL 6.16-6.1] wifi: mac80211: increase scan_ies_len for S1G
Date: Mon,  8 Sep 2025 20:30:11 -0400	[thread overview]
Message-ID: <20250909003025.2493540-1-sashal@kernel.org> (raw)

From: Lachlan Hodges <lachlan.hodges@morsemicro.com>

[ Upstream commit 7e2f3213e85eba00acb4cfe6d71647892d63c3a1 ]

Currently the S1G capability element is not taken into account
for the scan_ies_len, which leads to a buffer length validation
failure in ieee80211_prep_hw_scan() and subsequent WARN in
__ieee80211_start_scan(). This prevents hw scanning from functioning.
To fix ensure we accommodate for the S1G capability length.

Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20250826085437.3493-1-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Perfect! Now I have all the context I need. Let me provide my analysis:

## Backport Status: **YES**

### Extensive Analysis:

**This commit fixes a real bug that causes hardware scanning to fail for
S1G (802.11ah) WiFi devices.**

#### The Bug Details:

1. **Root Cause**: When commit `0333a81bc8343` ("wifi: mac80211: S1G
   capabilities information element in probe request") was merged in
   February 2023, it added S1G capability elements to probe requests.
   However, it failed to update the buffer size calculation
   (`scan_ies_len`) to account for these additional 17 bytes (2 byte
   element header + 15 byte `struct ieee80211_s1g_cap`).

2. **Failure Mechanism**:
   - In `__ieee80211_start_scan()` at net/mac80211/scan.c:755, the
     buffer size is calculated as `local->scan_ies_len + req->ie_len`
   - When `ieee80211_prep_hw_scan()` is called at line 870, it attempts
     to build probe request IEs using `ieee80211_build_preq_ies()`
   - The function `ieee80211_build_preq_ies_band()` checks buffer space
     and adds S1G capability for S1G bands (lines 1963-1965 in util.c)
   - Without the fix, the buffer is 17 bytes too small, causing
     `-ENOBUFS` to be returned
   - This triggers the `WARN_ON(!ieee80211_prep_hw_scan(sdata))` at line
     870, producing a kernel warning and aborting the scan

3. **User Impact**:
   - Produces a visible kernel WARNING in dmesg
   - Hardware scanning completely fails for S1G devices
   - The device cannot perform network discovery
   - This is a **functional regression** introduced in kernel 6.3 (when
     commit 0333a81bc8343 was merged)

#### Why This Should Be Backported:

1. **Fixes a Real Bug**: This is not a theoretical issue - it causes
   actual hardware scanning failures with kernel warnings for any
   S1G-capable hardware.

2. **Regression Fix**: This fixes a regression introduced by commit
   0333a81bc8343 in kernel 6.3. Any stable kernel that includes that
   commit needs this fix.

3. **Small and Contained**: The fix is minimal - just 4 lines of actual
   code changes:
   - Adding `supp_s1g` boolean variable
   - Setting it based on S1G capability presence
   - Adding 17 bytes to buffer calculation when S1G is supported

4. **No Side Effects**: The change only affects S1G-capable devices and
   simply ensures adequate buffer space. It cannot negatively impact
   non-S1G devices.

5. **Clear Bug Pattern**: This is a classic "forgot to update buffer
   size calculation" bug that's straightforward to understand and
   verify.

6. **Vendor Support**: MorseMicro is actively developing S1G hardware
   and drivers, making this functionality important for emerging
   IoT/long-range WiFi deployments.

#### Stable Tree Considerations:

- Should be backported to **kernel 6.3 and later** (where commit
  0333a81bc8343 exists)
- The fix applies cleanly as it only adds to existing initialization
  code
- No dependencies on other commits
- Follows stable tree rules: fixes an important bug with minimal risk

The commit message could have been clearer by mentioning this was a
regression from commit 0333a81bc8343, but the fix itself is correct and
necessary for S1G hardware to function properly.

 net/mac80211/main.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 1bad353d8a772..35c6755b817a8 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1136,7 +1136,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 	int result, i;
 	enum nl80211_band band;
 	int channels, max_bitrates;
-	bool supp_ht, supp_vht, supp_he, supp_eht;
+	bool supp_ht, supp_vht, supp_he, supp_eht, supp_s1g;
 	struct cfg80211_chan_def dflt_chandef = {};
 
 	if (ieee80211_hw_check(hw, QUEUE_CONTROL) &&
@@ -1252,6 +1252,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 	supp_vht = false;
 	supp_he = false;
 	supp_eht = false;
+	supp_s1g = false;
 	for (band = 0; band < NUM_NL80211_BANDS; band++) {
 		const struct ieee80211_sband_iftype_data *iftd;
 		struct ieee80211_supported_band *sband;
@@ -1299,6 +1300,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 			max_bitrates = sband->n_bitrates;
 		supp_ht = supp_ht || sband->ht_cap.ht_supported;
 		supp_vht = supp_vht || sband->vht_cap.vht_supported;
+		supp_s1g = supp_s1g || sband->s1g_cap.s1g;
 
 		for_each_sband_iftype_data(sband, i, iftd) {
 			u8 he_40_mhz_cap;
@@ -1432,6 +1434,9 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 		local->scan_ies_len +=
 			2 + sizeof(struct ieee80211_vht_cap);
 
+	if (supp_s1g)
+		local->scan_ies_len += 2 + sizeof(struct ieee80211_s1g_cap);
+
 	/*
 	 * HE cap element is variable in size - set len to allow max size */
 	if (supp_he) {
-- 
2.51.0


             reply	other threads:[~2025-09-09  0:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-09  0:30 Sasha Levin [this message]
2025-09-09  0:30 ` [PATCH AUTOSEL 6.16-5.4] wifi: mac80211: fix incorrect type for ret Sasha Levin
2025-09-09  0:30 ` [PATCH AUTOSEL 6.16-6.12] nvme: fix PI insert on write Sasha Levin
2025-09-09  0:30 ` [PATCH AUTOSEL 6.16-5.4] pcmcia: omap_cf: Mark driver struct with __refdata to prevent section mismatch Sasha Levin
2025-09-09  0:30 ` [PATCH AUTOSEL 6.16-5.4] ALSA: firewire-motu: drop EPOLLOUT from poll return values as write is not supported Sasha Levin
2025-09-09  0:30 ` [PATCH AUTOSEL 6.16] wifi: mt76: do not add non-sta wcid entries to the poll list Sasha Levin
2025-09-09  0:30 ` [PATCH AUTOSEL 6.16-6.6] wifi: wilc1000: avoid buffer overflow in WID string configuration Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250909003025.2493540-1-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=johannes.berg@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=lachlan.hodges@morsemicro.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).