From: Johannes Berg johannes.berg@intel.com
[ 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.I961ee41b8f10538a54b856... Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
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; }