[PATCH AUTOSEL 7.0-6.18] wifi: iwlwifi: mld: always assign a fw id to a vif

[Sasha Levin <sashal@kernel.org>]

From: Miri Korenblit <miriam.rachel.korenblit@intel.com>

[ Upstream commit 4f1da5cf31cf6345f145e914a0158c2e114bbe27 ]

We used to have a fw id assignment in iwl_mld_init_vif since all interface
types that were added to the driver was immediately added to the FW as
well.
Since NAN was introduced, this is no longer the case - the NAN interface
is not added to the fw until a local schedule is configured.

For this vif we don't assign a fw id so it is 0 by default.
But later, when the vif is removed from the driver, we think that it has
a valid fw id (0) and we point fw_id_to_vif[0] to NULL.
fw_id_to_vif[0] might actually point to another vif with a valid fw id
0. In this case, we end up messing fw_id_to_vif.

Fix this by initializing a vif with a special invalid fw id, and by
exiting iwl_mld_rm_vif early for NAN interfaces.

Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260321192637.f3b5cc59098f.I3d1dbe66bd224cbb786c2b0ab3d1c9f7ec9003e4@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Good. Now I have a complete picture. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `wifi: iwlwifi: mld:` (Intel wireless driver, MLD sub-
  driver)
- Action verb: "always assign" - implies fixing missing initialization
- Summary: Ensure every vif gets a proper fw_id (even NAN interfaces
  that don't get a real one)

Record: [wifi: iwlwifi: mld] [fix/ensure] [Initialize fw_id for NAN vifs
to prevent fw_id_to_vif table corruption]

**Step 1.2: Tags**
- Reviewed-by: Emmanuel Grumbach (Intel wifi subsystem co-maintainer)
- Signed-off-by: Miri Korenblit (Intel wifi maintainer)
- Link: patch.msgid.link URL
- No Fixes: tag (expected for candidates)
- No Cc: stable (expected for candidates)

Record: Reviewed by a subsystem co-maintainer. No syzbot, no external
reporters.

**Step 1.3: Commit Body Analysis**
The message clearly describes:
- The bug: NAN interfaces don't get a fw_id, so fw_id defaults to 0
- The symptom: On NAN vif removal, `fw_id_to_vif[0]` is set to NULL,
  which may belong to a *different* valid vif with fw_id 0
- The consequence: Corrupts the fw_id_to_vif mapping table
- The fix: Initialize fw_id to `IWL_MLD_INVALID_FW_ID` and skip rm_vif
  for NAN

Record: This is a data corruption bug in the vif-to-firmware-id mapping
table.

**Step 1.4: Hidden Bug Fix?**
This is clearly described as a bug fix. The commit message explains the
exact corruption mechanism.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/net/wireless/intel/iwlwifi/mld/iface.c`
- 2 hunks: one in `iwl_mld_init_vif()` (+1 line), one in
  `iwl_mld_rm_vif()` (+3 lines)
- Net: +4 lines. Extremely small, surgical fix.

**Step 2.2: Code Flow Change**

Hunk 1 (`iwl_mld_init_vif`): Adds `mld_vif->fw_id =
IWL_MLD_INVALID_FW_ID;` (0xff). Before: fw_id is 0 (zeroed struct).
After: fw_id is 0xff (invalid sentinel).

Hunk 2 (`iwl_mld_rm_vif`): Adds early return for NAN interfaces. Before:
NAN vif removal proceeds to NULL out `fw_id_to_vif[0]`. After: NAN
removal returns immediately without touching the table.

**Step 2.3: Bug Mechanism**
This is a **logic/correctness bug** leading to **data corruption** in
the fw_id_to_vif mapping:
1. NAN vif is created - fw_id stays at default 0 (no allocation)
2. NAN vif is removed - `fw_id_to_vif[0]` is set to NULL
3. If another vif legitimately holds fw_id 0, its mapping is destroyed

The existing WARN_ON check (`mld_vif->fw_id >=
ARRAY_SIZE(mld->fw_id_to_vif)`) doesn't catch this because 0 is a valid
index. But with the fix, IWL_MLD_INVALID_FW_ID (0xff) would trigger the
WARN_ON as a safety net.

**Step 2.4: Fix Quality**
- Obviously correct: IWL_MLD_INVALID_FW_ID already exists and is used
  elsewhere in the codebase (scan.c)
- Minimal: only 4 lines added
- No regression risk: NAN interfaces should never touch fw_id_to_vif,
  and the early return prevents any interaction
- Double defense: Both the sentinel value AND the early return prevent
  the corruption

## PHASE 3: GIT HISTORY

**Step 3.1: Blame Results**
- `iwl_mld_init_vif` was introduced by `d1e879ec600f9` (add iwlmld sub-
  driver, 2025-02-16), first in v6.15
- The NAN support that introduced the bug was `9e978d8ebbe96`
  (2025-11-10), first in v7.0
- The `iwl_mld_rm_vif` function has been unchanged since the mld driver
  introduction, with only the void return refactor in `0755db9f2605e`

Record: Bug introduced by commit 9e978d8ebbe96 in v7.0-rc1. Only v7.0+
stable trees are affected.

**Step 3.2: Fixes tag** - No Fixes: tag present (expected).

**Step 3.3: File History**
Post-v7.0 commits touching iface.c are only recent tree-wide changes and
the wifi generation fix. The file is stable.

**Step 3.4: Author**
Miri Korenblit is the primary maintainer of iwlwifi. Emmanuel Grumbach
reviewed the patch.

**Step 3.5: Dependencies**
- `IWL_MLD_INVALID_FW_ID` (0xff) already exists in v7.0 at `mld.h:530`
- NAN support already exists in v7.0
- No other prerequisites needed. This is standalone.

## PHASE 4: MAILING LIST RESEARCH

Lore was inaccessible due to anti-bot protection. b4 dig found the
submission URL: `https://patch.msgid.link/20260324093333.2953495-1-
miriam.rachel.korenblit@intel.com`. This was part of a batch submission
by Miri Korenblit. The patch was reviewed by Emmanuel Grumbach, the
iwlwifi co-maintainer.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Key Functions**
- `iwl_mld_init_vif()`: Called from `iwl_mld_add_vif()` during interface
  creation - standard mac80211 callback path
- `iwl_mld_rm_vif()`: Called during interface removal
- `fw_id_to_vif[]` is accessed from many places: notification handlers,
  low_latency, scan code - corruption of this table has wide-reaching
  effects

**Step 5.5: Similar Patterns**
`IWL_MLD_INVALID_FW_ID` is already used as a sentinel value for
`fw_link_id` in scan.c, so this pattern is established in the codebase.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
- NAN support (`9e978d8ebbe96`) first appeared in v7.0-rc1
- Not present in v6.19, v6.16, or v6.15
- Bug exists ONLY in v7.0 stable tree
- Current HEAD is v7.0, and we confirmed the v7.0 code has the bug

**Step 6.2: Backport Complications**
The diff between v7.0 and HEAD for this file is empty (HEAD IS v7.0).
The patch applies cleanly with no conflicts whatsoever.

**Step 6.3: No related fixes already in stable.**

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** wifi: iwlwifi is an IMPORTANT subsystem - Intel WiFi is
among the most widely used WiFi hardware on Linux (laptops, desktops).
Criticality: IMPORTANT.

**Step 7.2:** The iwlwifi mld driver is actively developed with NAN and
EMLSR features being added in the v7.0 cycle.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Users of Intel WiFi hardware using the iwlmld driver with NAN
functionality. As NAN is a new feature in v7.0, this primarily affects
users of newer WiFi 7 hardware.

**Step 8.2: Trigger Conditions**
- Create a NAN interface, then remove it. This will corrupt
  fw_id_to_vif[0].
- If another vif with fw_id 0 exists, it becomes invisible to the
  driver.
- Trigger: normal NAN usage lifecycle (create/destroy NAN interface)

**Step 8.3: Failure Mode**
- The fw_id_to_vif table corruption means the driver loses track of
  active interfaces
- This can cause: wrong vif returned from firmware notifications, NULL
  pointer dereferences when accessing the corrupted entry, incorrect
  driver behavior
- Severity: HIGH (data corruption of internal mapping, potential for
  subsequent crashes)

**Step 8.4: Risk-Benefit**
- BENEFIT: High - prevents corruption of critical internal data
  structure
- RISK: Very low - 4 lines, obviously correct, uses existing sentinel
  value, reviewed by co-maintainer
- Ratio: Strongly favorable

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes real data corruption bug in fw_id_to_vif mapping table
- Extremely small (4 lines), surgical, obviously correct
- Uses existing infrastructure (IWL_MLD_INVALID_FW_ID)
- Reviewed by subsystem co-maintainer Emmanuel Grumbach
- Applies cleanly to v7.0 (zero diff between HEAD and v7.0)
- No dependencies needed
- Bug is triggered by normal NAN usage lifecycle

AGAINST backporting:
- NAN is a new feature, so the user population is still growing
- No Fixes: tag or explicit stable nomination (but this is expected for
  all candidates)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? YES - trivial fix, reviewed by co-
   maintainer
2. Fixes a real bug? YES - fw_id_to_vif corruption on NAN vif removal
3. Important issue? YES - data corruption of internal driver state
4. Small and contained? YES - 4 lines in 1 file
5. No new features? Correct - pure bug fix
6. Can apply to stable? YES - applies cleanly to v7.0

**Step 9.3: Exception Categories** - Not applicable; this is a
straightforward bug fix.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Emmanuel Grumbach (Intel co-
  maintainer), Signed-off-by Miri Korenblit (maintainer)
- [Phase 2] Diff: +1 line in iwl_mld_init_vif (sentinel init), +3 lines
  in iwl_mld_rm_vif (NAN early return)
- [Phase 3] git blame: NAN support introduced in 9e978d8ebbe96
  (v7.0-rc1), confirmed via `git tag --contains`
- [Phase 3] git show 9e978d8ebbe96: confirmed it moved fw_id allocation
  out of init_vif without initializing to invalid for NAN
- [Phase 3] Verified `d1e879ec600f9b` (mld driver) first appeared in
  v6.15, NAN support only in v7.0
- [Phase 4] b4 dig found submission URL; lore inaccessible due to bot
  protection
- [Phase 5] IWL_MLD_INVALID_FW_ID (0xff) already exists in v7.0
  mld.h:530 and is used in scan.c
- [Phase 5] fw_id_to_vif[] accessed from iface.c, low_latency.c,
  notification handlers - wide impact surface
- [Phase 6] NAN not in v6.19, v6.16, or v6.15 (confirmed via `git show
  v6.19:...nan.c`). Bug only in v7.0
- [Phase 6] git diff v7.0..HEAD is empty for iface.c - patch applies
  cleanly
- [Phase 6] v7.0 code verified: iwl_mld_init_vif lacks fw_id init,
  iwl_mld_rm_vif lacks NAN check
- [Phase 7] fw_id is u8 inside zeroed_on_hw_restart struct_group,
  confirmed default is 0 (valid index)
- [Phase 8] Corruption path verified: NAN vif removed -> fw_id=0 ->
  fw_id_to_vif[0]=NULL -> corrupts valid mapping

This is a small, surgical, obviously correct fix for a real data
corruption bug in the iwlwifi mld driver's NAN handling. It meets all
stable kernel criteria and applies cleanly to v7.0.

**YES**

 drivers/net/wireless/intel/iwlwifi/mld/iface.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mld/iface.c b/drivers/net/wireless/intel/iwlwifi/mld/iface.c
index 9215fc7e2eca7..fb56e59894726 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/iface.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/iface.c
@@ -434,6 +434,7 @@ iwl_mld_init_vif(struct iwl_mld *mld, struct ieee80211_vif *vif)
 	lockdep_assert_wiphy(mld->wiphy);
 
 	mld_vif->mld = mld;
+	mld_vif->fw_id = IWL_MLD_INVALID_FW_ID;
 	mld_vif->roc_activity = ROC_NUM_ACTIVITIES;
 
 	if (!mld->fw_status.in_hw_restart) {
@@ -481,6 +482,10 @@ void iwl_mld_rm_vif(struct iwl_mld *mld, struct ieee80211_vif *vif)
 
 	lockdep_assert_wiphy(mld->wiphy);
 
+	/* NAN interface type is not known to FW */
+	if (vif->type == NL80211_IFTYPE_NAN)
+		return;
+
 	iwl_mld_mac_fw_action(mld, vif, FW_CTXT_ACTION_REMOVE);
 
 	if (WARN_ON(mld_vif->fw_id >= ARRAY_SIZE(mld->fw_id_to_vif)))
-- 
2.53.0