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 B6FDF3A5444; Mon, 20 Apr 2026 13:25:17 +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=1776691517; cv=none; b=JLk2qXccvGP3sm6bOWEkwH+P7CjrNS4kAj6bEMPZ5qM/sfhJ4iy5vgoTRNVRGCdKFr8cHthyg+R3oJo/7QMM58UWxu3FttfnShJTxnmm+eLr0sNNgrvKtX/y3djQwd18y2u6tu0g8DPAGwqZO+1GYQ0ptYQEsDxhcYoI4pM0tac= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776691517; c=relaxed/simple; bh=1tMwr7fKz198F+7PJAx76Ncs0+xGjN2tu4IcqbtjbiE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=snzBwz5aw92GjKvy/Ghb2blmrI1f3TmZ2cIedP8aRtPVwkhR2+lvUuTQxOJ28Cl8nUvcX8azbM+caC1uLBBBPTiAIu+m/z8XTDxSQLkJ6+VjbtBUB/urHo5/BeoZh6QGHpRIJ4v/FljKgrej3Ai1X3OX29+GkFVE8l9Lc3Isuac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j6dCnO9Y; 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="j6dCnO9Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2225C19425; Mon, 20 Apr 2026 13:25:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776691517; bh=1tMwr7fKz198F+7PJAx76Ncs0+xGjN2tu4IcqbtjbiE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j6dCnO9Yp+9dzF26xa9K2nSj+40pehzD4+uHt8A/VxUhlMCrswrT4w44XULqgdvMw SDPhE+CjshQhVyv9mNkjjG2REmo43oEu6trpphcBg0AJ4uHuE0lJfFLVzRmGHKGjWC cMaVcEptQ7waKss8OaHeGUlT4YatGAS3W06ClqKHChT6ZbT+j8AlK4/mbximBRDjBV eHn2c1BniVezAMmPDZbJXX0YmThVIEF6wJkoZhCGnb6yrbz4jV54SQnQ/5n1V5tn1B 8zAh6jPJFkdHuQJ1t9gP3LPk3l/ohEI+pZcXsM2dgVksn9fvN2L2NKSQi6xpZoMUD5 v/kFfXwk72rzQ== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Tamizh Chelvam Raja , Sathishkumar Muruganandam , Johannes Berg , Sasha Levin , johannes@sipsolutions.net, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 7.0-6.1] wifi: mac80211: use ap_addr for 4-address NULL frame destination Date: Mon, 20 Apr 2026 09:17:50 -0400 Message-ID: <20260420132314.1023554-76-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org> References: <20260420132314.1023554-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 7.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Tamizh Chelvam Raja [ Upstream commit 594be50a3f0a6b7389f40f7acbf0dd731beb5204 ] Currently ieee80211_send_4addr_nullfunc() uses deflink.u.mgd.bssid for addr1 and addr3 fields. In MLO configurations, deflink.u.mgd.bssid represents link 0's BSSID and is not updated when link 0 is not an assoc link. This causes 4-address NULL frames to be sent to the wrong address, preventing WDS AP_VLAN interface creation on the peer AP. To fix this use sdata->vif.cfg.ap_addr instead, which contains the AP's MLD address populated during authentication/association and remains valid regardless of which links are active. This ensures 4-address NULL frames reach the correct AP, allowing proper WDS operation over MLO connections. Co-developed-by: Sathishkumar Muruganandam Signed-off-by: Sathishkumar Muruganandam Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260326164723.553927-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Now I have all the information I need for the complete analysis. Let me compile the findings. --- ## PHASE 1: COMMIT MESSAGE FORENSICS ### Step 1.1: Parse the Subject Line - **Subsystem:** wifi: mac80211 - **Action verb:** "use" (corrective - implying the current usage is wrong) - **Summary:** Use the correct AP address (`ap_addr`) instead of deflink BSSID for 4-address NULL frame destination in MLO configurations. Record: [wifi: mac80211] [use/fix] [Correct the destination address for 4-addr NULL frames in MLO mode] ### Step 1.2: Parse All Tags - **Co-developed-by:** Sathishkumar Muruganandam - **Signed-off-by:** Sathishkumar Muruganandam, Tamizh Chelvam Raja (author), Johannes Berg (maintainer) - **Link:** https://patch.msgid.link/20260326164723.553927-3- tamizh.raja@oss.qualcomm.com - **No Fixes: tag** (expected - that's why it needs review) - **No Reported-by:** (likely found through code review / internal testing at Qualcomm) - **No Cc: stable** (expected) Johannes Berg is the mac80211 maintainer who signed off — strong trust signal. Record: Co-developed by Qualcomm engineers, committed by mac80211 maintainer Johannes Berg. Message-id suggests this is patch 3 of a series. ### Step 1.3: Analyze the Commit Body - **Bug:** `deflink.u.mgd.bssid` represents link 0's BSSID which is NOT updated when link 0 is not an assoc link in MLO configurations - **Symptom:** 4-address NULL frames are sent to the WRONG address, preventing WDS AP_VLAN interface creation on the peer AP - **Root cause:** Wrong field used for destination address in MLO mode - **Fix:** Use `sdata->vif.cfg.ap_addr` which contains the AP's MLD address populated during authentication/association Record: Bug is that WDS (4-addr mode) over MLO connections is completely broken. Frames go to wrong AP address, preventing the AP from creating VLAN interfaces for the client. ### Step 1.4: Detect Hidden Bug Fixes This is clearly a bug fix, not hidden. The commit message explicitly describes broken functionality (wrong destination address for 4-addr NULL frames in MLO). Record: This is an explicit bug fix for MLO+WDS functionality. --- ## PHASE 2: DIFF ANALYSIS ### Step 2.1: Inventory the Changes - **File:** `net/mac80211/mlme.c` - **Lines changed:** 2 lines modified (addr1 and addr3 source changed) - **Function modified:** `ieee80211_send_4addr_nullfunc()` - **Scope:** Single-file, surgical, 2-line fix Record: 1 file, 2 lines changed. Scope: minimal surgical fix. ### Step 2.2: Code Flow Change - **Before:** `memcpy(nullfunc->addr1, sdata->deflink.u.mgd.bssid, ...)` and same for addr3 - **After:** `memcpy(nullfunc->addr1, sdata->vif.cfg.ap_addr, ...)` and same for addr3 - **Path affected:** The 4-address NULL frame construction path (called during association and interface config change) Record: Only the source of the MAC address for addr1/addr3 fields changes. Both are ETH_ALEN copies from valid struct members. ### Step 2.3: Bug Mechanism Category: **Logic/correctness fix** — wrong data source used for frame addresses in MLO. - In non-MLO: `deflink.u.mgd.bssid` == `vif.cfg.ap_addr`, so behavior is unchanged - In MLO: `deflink.u.mgd.bssid` may point to an uninitialized/wrong link 0 BSSID, while `vif.cfg.ap_addr` correctly holds the AP MLD address Record: Logic bug — wrong field referenced for AP address in MLO mode. Fix uses the documented correct field. ### Step 2.4: Fix Quality - **Obviously correct?** YES — `vif.cfg.ap_addr` is documented as "AP MLD address, or BSSID for non-MLO connections" which is exactly what's needed here. - **Minimal?** YES — 2 lines changed. - **Regression risk?** Virtually zero — the same pattern was applied in commit 8a9be422f5ff3 for tx.c paths, and `ap_addr` is already used extensively in the same file for the same purpose. Record: Fix is obviously correct, minimal, follows established precedent. Zero regression risk. --- ## PHASE 3: GIT HISTORY INVESTIGATION ### Step 3.1: Blame the Changed Lines - The buggy `sdata->deflink.u.mgd.bssid` was introduced by commit **bfd8403adddd09** ("wifi: mac80211: reorg some iface data structs for MLD") from May 2022 by Johannes Berg. - Before that commit, the code used `sdata->u.mgd.bssid` which was fine for non-MLO. - The deflink reorg moved things to per-link structures but didn't update this function to use the MLD-aware `ap_addr` for address fields. Record: Buggy code introduced in bfd8403adddd09 (May 2022), present in v6.1+. ### Step 3.2: Fixes Tag No Fixes: tag present. The implicit Fixes target is bfd8403adddd09. Record: No explicit Fixes tag. Implicit target is bfd8403adddd09 (in v6.1+). ### Step 3.3: Related Changes - Commit **8a9be422f5ff3** ("wifi: mac80211: tx: use AP address in some places for MLO") by Johannes Berg himself did the exact same fix pattern for tx.c paths — changing `deflink.u.mgd.bssid` to `vif.cfg.ap_addr`. This was the same class of bug that was missed in `ieee80211_send_4addr_nullfunc()`. Record: Strong precedent exists (8a9be422f5ff3). This is a missed instance of the same fix pattern. ### Step 3.4: Author Context - Authors are Qualcomm engineers (Tamizh Chelvam Raja, Sathishkumar Muruganandam) - Committed by Johannes Berg (mac80211 maintainer) - The maintainer's sign-off indicates review and approval Record: Fix accepted by subsystem maintainer. ### Step 3.5: Dependencies - `ap_addr` field exists since commit b65567b03c9502 (June 2022), which is in v6.1+ - The `deflink` structure exists since bfd8403adddd09, also in v6.1+ - No code dependencies beyond what exists in stable trees Record: No additional dependencies. All required structures exist in v6.1+. --- ## PHASE 4: MAILING LIST RESEARCH ### Step 4.1-4.5 Lore.kernel.org was blocked by anti-bot protection. b4 dig couldn't find the commit (it's not yet in the tree as an applied commit). The Link: tag in the commit message references `20260326164723.553927-3-tamizh.raja@oss.qualcomm.com`, suggesting this is patch 3 of a series. The commit was signed off by Johannes Berg (mac80211 maintainer), which is a strong quality indicator. Record: Could not access lore discussion. Maintainer sign-off verified. --- ## PHASE 5: CODE SEMANTIC ANALYSIS ### Step 5.1: Key Functions Modified function: `ieee80211_send_4addr_nullfunc()` ### Step 5.2: Callers Two call sites: 1. `net/mac80211/mlme.c:6555` — called during `ieee80211_assoc_success()` when `ifmgd->use_4addr` is true 2. `net/mac80211/cfg.c:298` — called when 4addr mode is enabled via `ieee80211_change_iface()` Record: Called from association path and interface config path. Both are normal operational paths. ### Step 5.3-5.4: Call Chain The function is reachable when: - A station associates with 4-addr mode (WDS) enabled → common for mesh/backhaul setups - A user enables 4-addr mode via nl80211/iw Record: Reachable from normal user operations (association, interface config). ### Step 5.5: Similar Patterns The same bug pattern (`deflink.u.mgd.bssid` → `vif.cfg.ap_addr`) was fixed in tx.c (commit 8a9be422f5ff3). There are still 8 remaining instances of `deflink.u.mgd.bssid` in mlme.c — some may be correct (link-specific operations) while others might need similar fixes. Record: Same pattern was already fixed in tx.c. This is a remaining instance. --- ## PHASE 6: STABLE TREE ANALYSIS ### Step 6.1: Does Buggy Code Exist in Stable? - `deflink.u.mgd.bssid` was introduced by bfd8403adddd09 — confirmed in v6.1+ - `vif.cfg.ap_addr` was introduced by b65567b03c9502 — confirmed in v6.1+ - Both structures exist in all active stable trees (6.1.y, 6.6.y, 6.12.y) Record: Buggy code exists in v6.1+ stable trees. ### Step 6.2: Backport Complications - mlme.c has had 233 changes since v6.6, so context may differ - However, the function `ieee80211_send_4addr_nullfunc()` is self- contained and hasn't changed much - The 2-line fix should apply cleanly or with trivial context adjustment Record: Minor context conflicts possible but fix is self-contained. Low backport difficulty. ### Step 6.3: Related Fixes Already in Stable The precedent fix 8a9be422f5ff3 (tx.c changes) is in v6.1+, establishing that `ap_addr` is the correct field for MLO-aware AP addressing. Record: Precedent fix already in stable trees. --- ## PHASE 7: SUBSYSTEM CONTEXT ### Step 7.1: Subsystem Criticality - **Subsystem:** net/mac80211 (WiFi) - **Criticality:** IMPORTANT — WiFi is critical for many users; 4-addr/WDS mode is used in enterprise mesh/backhaul Record: IMPORTANT subsystem. WiFi WDS used in enterprise/mesh deployments. ### Step 7.2: Activity mac80211 is very actively developed, especially around MLO support. Record: Highly active subsystem. --- ## PHASE 8: IMPACT AND RISK ASSESSMENT ### Step 8.1: Who is Affected Users running MLO (WiFi 7) connections with 4-addr/WDS mode enabled. This is a specific but real use case (enterprise mesh backhaul over WiFi 7). Record: Affected: MLO + WDS users. Growing user base as WiFi 7 adoption increases. ### Step 8.2: Trigger Conditions - Triggerable whenever an MLO station associates with 4-addr mode enabled - Requires MLO-capable hardware and AP - No special privileges needed beyond configuring 4-addr mode Record: Triggered on every MLO+WDS association. 100% reproducible for affected configurations. ### Step 8.3: Failure Mode Severity - **Not a crash** — the frame is sent to the wrong address - **Functional failure** — WDS doesn't work at all over MLO (AP can't create VLAN interface) - **Severity: MEDIUM-HIGH** — Complete feature breakage for affected users, but no data corruption/crash Record: Severity MEDIUM-HIGH — complete WDS functionality failure over MLO. ### Step 8.4: Risk-Benefit Ratio - **Benefit:** Enables WDS/4-addr mode to work over MLO connections (currently completely broken) - **Risk:** 2-line change to memcpy source, using a well-documented field already used extensively elsewhere. Virtually zero regression risk. - **Ratio:** Very favorable — HIGH benefit, VERY LOW risk Record: HIGH benefit, VERY LOW risk. --- ## PHASE 9: FINAL SYNTHESIS ### Step 9.1: Evidence Summary **FOR backporting:** - Fixes real broken functionality (WDS over MLO completely non- functional) - Extremely small fix (2 lines) that is obviously correct - Uses `ap_addr` which is documented as "AP MLD address, or BSSID for non-MLO" - Follows established precedent (commit 8a9be422f5ff3 did the same fix for tx.c) - `ap_addr` is already used ~20+ times in the same file for the same purpose - Accepted by mac80211 maintainer Johannes Berg - No behavior change for non-MLO configurations - All required data structures exist in stable trees (v6.1+) **AGAINST backporting:** - No Fixes: or Cc: stable tags (expected for AUTOSEL candidates) - MLO is relatively new and may not have many stable users yet - Not a crash/security/corruption bug — it's a functional regression - Part of a series (patch 3/N — other patches may or may not be needed) **UNRESOLVED:** - Could not access lore discussion to check if series patches are independent - Could not verify exact stable tree code state ### Step 9.2: Stable Rules Checklist 1. **Obviously correct and tested?** YES — change to documented correct field, accepted by maintainer 2. **Fixes a real bug?** YES — WDS over MLO doesn't work at all 3. **Important issue?** MEDIUM-HIGH — complete feature breakage for MLO+WDS users 4. **Small and contained?** YES — 2 lines in one function 5. **No new features?** Correct — no new features 6. **Can apply to stable?** YES — all required structures present in v6.1+ ### Step 9.3: Exception Categories Not an exception category — this is a standard bug fix. ### Step 9.4: Decision The fix is tiny, obviously correct, follows an established pattern from the maintainer, fixes real broken functionality, and carries virtually zero regression risk. While it's not a crash or security fix, it fixes complete feature breakage for WDS over MLO — a real use case for enterprise WiFi deployments. The 2-line change is the kind of surgical fix that stable trees are designed to accept. --- ## Verification - [Phase 1] Parsed tags: Co-developed-by from Qualcomm, SOB from mac80211 maintainer Johannes Berg - [Phase 2] Diff analysis: 2 lines changed in `ieee80211_send_4addr_nullfunc()`, changing memcpy source from `sdata->deflink.u.mgd.bssid` to `sdata->vif.cfg.ap_addr` - [Phase 3] git blame: Buggy lines introduced by bfd8403adddd09 (May 2022, Johannes Berg), confirmed in v6.1 via `git merge-base --is- ancestor` - [Phase 3] Confirmed precedent commit 8a9be422f5ff3 exists doing same fix pattern for tx.c - [Phase 3] `ap_addr` field introduced by b65567b03c9502, confirmed present in v6.1 and v6.6 - [Phase 5] Found 2 callers: mlme.c:6555 (assoc path) and cfg.c:298 (interface config) - [Phase 5] Verified `vif.cfg.ap_addr` is used extensively in mlme.c (~20+ instances) for same purpose - [Phase 5] Verified `ap_addr` documented as "AP MLD address, or BSSID for non-MLO connections" - [Phase 6] Confirmed buggy code and required structures exist in v6.1.y and v6.6.y stable trees - [Phase 8] Failure mode: WDS completely non-functional over MLO, severity MEDIUM-HIGH - UNVERIFIED: Could not access lore discussion to check series independence (anti-bot protection) - UNVERIFIED: Exact patch applicability to specific stable tree branches not tested **YES** net/mac80211/mlme.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 68da06434bb5d..200a075c97c9c 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -2496,9 +2496,9 @@ void ieee80211_send_4addr_nullfunc(struct ieee80211_local *local, fc = cpu_to_le16(IEEE80211_FTYPE_DATA | IEEE80211_STYPE_NULLFUNC | IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS); nullfunc->frame_control = fc; - memcpy(nullfunc->addr1, sdata->deflink.u.mgd.bssid, ETH_ALEN); + memcpy(nullfunc->addr1, sdata->vif.cfg.ap_addr, ETH_ALEN); memcpy(nullfunc->addr2, sdata->vif.addr, ETH_ALEN); - memcpy(nullfunc->addr3, sdata->deflink.u.mgd.bssid, ETH_ALEN); + memcpy(nullfunc->addr3, sdata->vif.cfg.ap_addr, ETH_ALEN); memcpy(nullfunc->addr4, sdata->vif.addr, ETH_ALEN); IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT; -- 2.53.0