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
next 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).