From: Johannes Berg johannes.berg@intel.com
[ Upstream commit 8f24be708829854560e1db9f765c51305b046183 ]
While waiting for a beacon after CSA, reset the CRC valid so that the next beacon is handled even if it happens to be identical the last one on the old channel. This is an AP bug either way, but it's better to disconnect cleanly than to have lingering CSA state.
In the iwlwifi instantiation of this problem, mac80211 is ignoring the beacon but the firmware creates a new CSA, and then crashes later because mac80211/driver didn't do anything about it.
Signed-off-by: Johannes Berg johannes.berg@intel.com Reviewed-by: Emmanuel Grumbach emmanuel.grumbach@intel.com Signed-off-by: Miri Korenblit miriam.rachel.korenblit@intel.com Link: https://patch.msgid.link/20251019115024.521ad9c6b87d.I86376900df3d3423185b75... Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Now I understand the full picture! Let me put together the final analysis:
## Summary Analysis
### 1. COMMIT MESSAGE ANALYSIS
**Subject:** "wifi: mac80211: reset CRC valid after CSA"
**Key points from commit message:** - Fixes a bug where the beacon CRC matching causes the first beacon after CSA to be ignored - This happens when an AP (like Asus AXE11000) sends an identical beacon after CSA - When ignored, mac80211 doesn't complete the CSA cleanup properly - In iwlwifi, this causes firmware to create a new CSA and eventually crash
**Tags:** - **NO** `Cc: stable@vger.kernel.org` tag - The maintainer did NOT explicitly request stable backport - **NO** `Fixes:` tag - There's no explicit reference to a buggy commit
### 2. CODE CHANGE ANALYSIS
The fix is extremely small - just **1 line of actual code** plus a **9-line comment**:
```c link->u.mgd.beacon_crc_valid = false; ```
This line is added at line 2509 in `ieee80211_csa_switch_work()`, right after: ```c link->u.mgd.csa.waiting_bcn = true; ```
**Technical mechanism:** 1. mac80211 uses a CRC mechanism to skip processing beacons that haven't changed 2. After CSA, the code sets `waiting_bcn = true` to wait for the first beacon on the new channel 3. The first beacon should normally be different (CSA IE removed), but some buggy APs send identical beacons 4. If the beacon CRC matches the last beacon on the old channel and `beacon_crc_valid` is still true, mac80211 skips processing 5. This leaves the CSA in a "waiting" state indefinitely 6. The iwlwifi firmware sees the beacon, detects CSA state, and creates a new CSA event, eventually crashing
**Root cause:** The `beacon_crc_valid` flag wasn't reset when entering the CSA waiting state.
### 3. HISTORICAL CONTEXT
This is a **regression fix** from commit `f3dee30c6791e` "wifi: mac80211: mlme: unify CSA handling" (introduced in v6.9): - That commit removed `beacon_crc_valid = false` from `ieee80211_chswitch_post_beacon()` - The rationale was "the CRC will change due to CSA/ECSA elements" - But this assumption was wrong for some buggy APs
The original fix `d6843d1ee2831` "mac80211: clear the beacon's CRC after channel switch" (2021) recognized this need but was in a different location in the old code structure.
### 4. CLASSIFICATION
- **Type:** Bug fix (not a feature) - **Category:** Crash fix / firmware hang fix - **Exception categories:** None (this is a pure bug fix) - **Security:** No CVE mentioned, not a security issue
### 5. SCOPE AND RISK ASSESSMENT
- **Lines changed:** ~10 lines (1 functional, 9 comment) - **Files touched:** 1 (net/mac80211/mlme.c) - **Complexity:** Very low - single boolean assignment - **Risk:** Very low - the change is conservative (invalidating CRC forces re-processing) - **Worst case if fix is wrong:** Slightly more beacon processing work (negligible) - **Subsystem:** WiFi mac80211 - mature, well-tested
### 6. USER IMPACT
- **Who is affected:** Users with Intel WiFi (iwlwifi) connecting to certain APs (like Asus AXE11000) - **Severity:** HIGH - causes firmware crash - **Reproducibility:** Specific AP behavior needed, but real-world bug - **Trigger:** CSA (Channel Switch Announcement) - common in enterprise environments
### 7. STABILITY INDICATORS
- **Tested-by:** Not present - **Reviewed-by:** Emmanuel Grumbach (Intel WiFi maintainer) ✓ - **Author:** Johannes Berg (mac80211 maintainer) - highly trusted - **Time in mainline:** Recent (Oct 2025) - not much soak time
### 8. DEPENDENCY CHECK
**CRITICAL:** This fix requires commit `f3dee30c6791e` "wifi: mac80211: mlme: unify CSA handling" which: - Is present in v6.9+ - Is present in stable/linux-6.9.y, 6.10.y, 6.11.y, 6.12.y, etc. - Is **NOT** present in stable/linux-6.6.y (LTS) or stable/linux-6.1.y (LTS)
For older stable trees (6.6.y, 6.1.y), this fix doesn't apply because: 1. The code structure is completely different 2. The original `beacon_crc_valid = false` is still in `ieee80211_chswitch_post_beacon()` 3. The bug was introduced by `f3dee30c6791e` which isn't in those trees
### VERDICT
**Arguments FOR backporting:** 1. Fixes a real firmware crash that affects users 2. Small, surgical fix - single line of actual code 3. Low risk - conservative change (invalidating CRC is safe) 4. Written by mac80211 maintainer, reviewed by iwlwifi maintainer 5. Fixes a regression from `f3dee30c6791e`
**Arguments AGAINST backporting:** 1. No `Cc: stable` tag - maintainer didn't request it 2. No `Fixes:` tag 3. Only applies to kernels 6.9+ (those with the prerequisite commit) 4. Relatively new commit (limited soak time) 5. Requires specific buggy AP to trigger
**Risk vs Benefit:** - Risk: Very low (trivial change, conservative behavior) - Benefit: Medium-high (prevents firmware crashes for users with affected APs)
The commit fixes a real crash scenario in iwlwifi with certain APs, is extremely small and low-risk, and was reviewed by the relevant maintainers. The lack of `Cc: stable` tag might be an oversight given the fix's nature. However, it only applies to kernels 6.9+ where the prerequisite CSA refactoring exists.
For stable trees 6.9+, 6.10+, 6.11+, 6.12+, this should be backported as it fixes a real user-visible crash with very low risk.
**YES**
net/mac80211/mlme.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index f3138d1585353..a231e8661e39d 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -2508,6 +2508,16 @@ static void ieee80211_csa_switch_work(struct wiphy *wiphy,
link->u.mgd.csa.waiting_bcn = true;
+ /* + * The next beacon really should always be different, so this should + * have no effect whatsoever. However, some APs (we observed this in + * an Asus AXE11000), the beacon after the CSA might be identical to + * the last beacon on the old channel - in this case we'd ignore it. + * Resetting the CRC will lead us to handle it better (albeit with a + * disconnect, but clearly the AP is broken.) + */ + link->u.mgd.beacon_crc_valid = false; + /* apply new TPE restrictions immediately on the new channel */ if (link->u.mgd.csa.ap_chandef.chan->band == NL80211_BAND_6GHZ && link->u.mgd.conn.mode >= IEEE80211_CONN_MODE_HE) {