[PATCH AUTOSEL 6.18] wifi: iwlwifi: mld: cancel wiphy work before freeing wiphy

[Sasha Levin <sashal@kernel.org>]

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

[ Upstream commit c99bc4d4e0ba6f4661b2b914c96a597d26e7cc05 ]

When we fail to load the fw during op-mode start, we purge the list
of the async handlers but we don't cancel the work.
Same when we stop the op-mode.

Before freeing wiphy, we need to cancel/flush any pending wiphy work,
otherwise the work will fire with a freed memory.
cfg80211 will do it anyway, but it will warn.

Cancel the work in those cases.

Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260714165826.07aa49f755a2.I734a27b1b0eeb5b0e821aee3318fee8dc0a6bc03@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have enough to decide: this is a small UAF/WARN fix in iwlwifi MLD,
the buggy path exists in this 7.3-rc4 tree, and the change is self-
contained.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**
Record: `[iwlwifi/mld] [cancel] cancel wiphy work before freeing wiphy`
- Subsystem: `wifi: iwlwifi: mld`
- Action verb: **cancel** (prevent leftover work from running after
  teardown)
- Intent: stop pending `wiphy_work` before `ieee80211_free_hw()` so it
  cannot run against freed memory

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- `Reviewed-by: Johannes Berg <johannes.berg@intel.com>` —
  mac80211/cfg80211 and iwlwifi maintainer
- `Link: https://patch.msgid.link/20260714165826.07aa49f755a2.I734a27b1b
  0eeb5b0e821aee3318fee8dc0a6bc03@changeid`
- `Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>`
  (author; ignore any Sasha Levin SOB)
- **No** `Fixes:`, **no** `Cc: stable`, **no** `Reported-by`, **no**
  `Tested-by` — expected for this review pipeline
- Notable: maintainer Reviewed-by; no syzbot/KASAN report in the message

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** On op-mode start firmware-load failure, async handler *list*
  is purged (`iwl_mld_stop_fw()` →
  `iwl_mld_cancel_async_notifications()`), but `async_handlers_wk` is
  not cancelled. Same gap on op-mode stop.
- **Symptom:** Pending wiphy work can run after `ieee80211_free_hw()`;
  cfg80211 still drains/cancels and **WARNs**.
- **Failure mode:** use-after-free of wiphy/`iwl_mld` if the work runs;
  otherwise `WARN_ON(!list_empty(&rdev->wiphy_work_list))` in
  `cfg80211_dev_free()`.
- **Root cause:** cancel of `async_handlers_wk` was removed from the
  generic purge helper; start-fail/stop still free the wiphy with work
  queued.
- **Version info in message:** none

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not disguised. Explicit teardown correctness / UAF-prevention.
Not style cleanup.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/net/wireless/intel/iwlwifi/mld/mld.c` — **+3 lines**, 0
  removed (`git show --stat`: 3 insertions)
- Functions: `iwl_op_mode_mld_start()`, `iwl_op_mode_mld_stop()`
- Scope: **single-file surgical fix**

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
Hunk 1 (`iwl_op_mode_mld_start`, firmware/NVM failure):
- **Before:** `wiphy_unlock` → `rtnl_unlock` → `goto err` →
  `ieee80211_free_hw()` with `async_handlers_wk` possibly still on
  `wiphy_work_list`.
- **After:** `wiphy_work_cancel(mld->wiphy, &mld->async_handlers_wk)`
  while `wiphy_lock` is still held, then unlock/free.
- Path: **error path** (fw load or NVM read failure during probe/op-mode
  start).

Hunk 2 (`iwl_op_mode_mld_stop`):
- **Before:** lock, `iwl_mld_low_latency_stop` /
  `iwl_mld_deinit_time_sync`, unlock, `ieee80211_unregister_hw` /
  `ieee80211_free_hw`.
- **After:** same, but cancel `async_handlers_wk` under the wiphy lock
  first.
- Path: **teardown** (module unload / transport op-mode leave).

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record:
- **Category:** memory safety (use-after-free of work item / wiphy) +
  leftover-work WARN
- **Mechanism:** `wiphy_work_queue()` during RX after ALIVE;
  `iwl_mld_stop_fw()` purges `async_handlers_list` but (after
  59a5876e474ac) no longer cancels the work. `ieee80211_free_hw()` →
  `wiphy_free()` → `cfg80211_dev_free()` WARNs if the list is non-empty.
  Worker `cfg80211_wiphy_work()` can also run
  `iwl_mld_async_handlers_wk()` after unlock and race teardown.
- **Fix:** `wiphy_work_cancel()` under the wiphy mutex (required by
  `lockdep_assert_held(&wiphy->mtx)` in `wiphy_work_cancel()`).

**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: both sites already hold `wiphy_lock`; cancel of a
  not-queued work is a no-op (`list_empty` check in
  `wiphy_work_cancel()`).
- Minimal; no API/data-structure change.
- Regression risk: **very low**. Cancel vs flush is appropriate here (do
  not run handlers from a dead/going-away FW). Does not restore the lock
  requirement on `iwl_mld_cancel_async_notifications()`.
- Residual (pre-existing, not introduced here): NVM-fail path still does
  not call `iwl_mld_stop_fw()`; cancel avoids running those handlers
  during free. That is strictly safer than leaving work queued.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Surrounding start-fail/stop skeleton: `d1e879ec600f9` (“wifi: iwlwifi:
  add iwlmld sub-driver”, 2025-02/03) — first appeared in **v6.15**.
- The two new cancel lines: `c99bc4d4e0ba6` (this commit, 2026-07-14).
- Stop-path `wiphy_lock` wrapper: `83128399f3b492` (Benjamin Berg,
  2025-05).

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No `Fixes:` tag. Historical chain (verified with `git show` /
`git log -S`):
1. `4f7a07791944e` (2025-04, Fixes: d1e879ec600f9) — cancel async notifs
   on start failure specifically because work can run after
   `ieee80211_free_hw` (**UAF**).
2. `833026098b2d9` — fold cancel+purge into
   `iwl_mld_cancel_async_notifications()`.
3. **`59a5876e474ac` (2026-05-26, in v7.2, not in v7.1)** — **removed**
   `wiphy_work_cancel()` from that helper so it can run without the
   wiphy lock. That **reopened** the free-without-cancel hole.
4. This commit puts cancel back on the two paths that actually free the
   wiphy.

`59a5876e474ac` **is** an ancestor of this tree (`git merge-base --is-
ancestor` → yes via v7.2).

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record:
- Nearby: `a40ad60a47f7c` purge-on-NIC-error; `59a5876e474ac` remove
  cancel from helper.
- This is **not** patch-dependent on other hunks in the 15-patch
  iwlwifi-next dump; parent is unrelated `21b3263b90e80` (“mvm: validate
  monitor notif link_id”).
- Standalone: **yes**.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Miri Korenblit is a primary iwlwifi MLD author (driver
introduction and most async-handler work). Johannes Berg reviewed. High
confidence in the diagnosis.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record:
- Needs `wiphy_work_*` and `struct wiphy_work async_handlers_wk` —
  present since MLD intro in this tree.
- Needs the start-fail `if (ret)` / stop `wiphy_lock` shape — present.
- Needs `59a5876e474ac` as the regression that made cancel missing; that
  commit is in this tree.
- **Can apply standalone: yes** (already an ancestor of HEAD).

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c c99bc4d4e0ba6`: **[PATCH iwlwifi-next 08/15]**
  https://patch.msgid.link/20260714143119.07aa49f755a2.I734a27b1b0eeb5b0
  e821aee3318fee8dc0a6bc03@changeid
- `b4 dig -a`: v1 then **v2** “wifi: iwlwifi: updates - 07-14-2026”
  https://patch.msgid.link/20260714165826.07aa49f755a2.I734a27b1b0eeb5b0
  e821aee3318fee8dc0a6bc03@changeid
  Committed `Link:` is **v2** (latest).
- Lore WebFetch returned **403**; patchwork bot-blocked. Review body
  beyond tags is **UNVERIFIED**. No NAK found in b4 metadata.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record (`b4 dig -w`): Miri Korenblit; Johannes Berg
(`johannes@sipsolutions.net` / intel.com); `linux-
wireless@vger.kernel.org`. Maintainer was To/Cc and `Reviewed-by`.

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No `Reported-by` / bugzilla / syzbot. Author-found from code
(consistent with 4f7a077’s earlier UAF write-up). User count:
**UNVERIFIED**, but the start-fail path is firmware-load failure — a
real probe path.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: 08/15 of a mixed iwlwifi-next batch, not a dependent 1/N fix
series. Parent commit unrelated. No other series patch required for this
hunk.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: WebSearch of lore.kernel.org/stable for this subject did **not**
find a stable-specific thread. **UNVERIFIED** that anyone nominated or
rejected it on stable@ (absence of Cc:stable is expected).

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: `iwl_op_mode_mld_start`, `iwl_op_mode_mld_stop`. Related
callees: `wiphy_work_cancel`, `iwl_mld_load_fw`, `iwl_mld_stop_fw`,
`ieee80211_free_hw`.

**Step 5.2: TRACE CALLERS**
Record:
- `iwl_mld_ops.start = iwl_op_mode_mld_start` — op-mode start from
  iwlwifi transport when `iwlmld` is selected
  (`iwl_opmode_register("iwlmld", ...)`).
- Stop is the matching `.stop` callback on unbind/unload.
- Context: process, probe/remove — not IRQ. Reachable whenever
  CONFIG_IWLMLD hardware probes or the module is removed.

**Step 5.3: TRACE CALLEES**
Record:
- Start-fail: `iwl_mld_load_fw()` on error after ALIVE calls
  `iwl_mld_stop_fw()` → purges list, does **not** cancel work.
- Then `ieee80211_free_hw()` → `wiphy_free()` → `put_device()` →
  `wiphy_dev_release()` → `cfg80211_dev_free()` which
  `WARN_ON(!list_empty(&rdev->wiphy_work_list))` then
  `cancel_work_sync(&rdev->wiphy_work)`.
- Worker: `cfg80211_wiphy_work()` → `wk->func` →
  `iwl_mld_async_handlers_wk()`.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Userspace/admin trigger: load iwlwifi on MLD firmware (Wi-Fi 7
Intel), failed firmware/NVM, or unload. Not a syscall exploit path;
**driver probe/remove**. Common enough for production laptops.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: MVM already cancels/flushes analog work in `iwl_mvm_mac_stop()`
(`wiphy_work_cancel` on `async_handlers_wiphy_wk`). MLD
`iwl_mld_mac80211_stop()` already cancels `add_txqs_wk` but **not**
`async_handlers_wk`. This commit aligns MLD teardown with that rule.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record:
- Local tree: **v7.3-rc4** (`git describe HEAD` →
  `v7.3-rc4-27-gf0100363d8c37`; `VERSION=7 PATCHLEVEL=3 SUBLEVEL=0
  EXTRAVERSION=-rc4`).
- MLD driver **present**
  (`drivers/net/wireless/intel/iwlwifi/mld/mld.c`).
- Regression `59a5876e474ac` **is** in this history (v7.2+).
- Current file already contains both `wiphy_work_cancel` calls (this
  commit is ancestor of HEAD). Pre-fix parent of `c99bc4d4e0ba6` matches
  the supplied diff exactly.
- Bug was introduced **before** this 7.3 branch (in v7.2), not after.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: **Clean apply** on this tree (already applied). Surrounding
`iwl_op_mode_mld_start`/`stop` matches the patch. `wiphy_work_cancel`
exists in `net/wireless/core.c`.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: `4f7a07791944e` / `833026098b2d9` / `59a5876e474ac` are all
here. No alternate fix of this hole besides `c99bc4d4e0ba6`. `git log
--grep='cancel wiphy work'` only this commit.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: `drivers/net/wireless/intel/iwlwifi/mld` — Intel Wi-Fi MLD
(CONFIG_IWLMLD). **IMPORTANT** (shipping Wi-Fi 7 NICs), not core mm/VFS,
not staging.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Very active (NAN, RSC, scan, firmware API churn in recent `git
log` on `mld.c`). Mature enough that this is a teardown correctness fix,
not new-feature scaffolding.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: **driver-specific / config-specific** — CONFIG_IWLMLD users
(Intel MLD firmware devices). Not universal.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record:
- Start-fail: firmware load/init failure after ALIVE (missing/bad fw,
  PNVM/init timeout) — **realistic probe path**.
- Stop: op-mode teardown/unload.
- Timing: leftover `wiphy_work` after list purge.
- Unprivileged trigger: only if an unprivileged user can unload the
  driver or force fw failure — typically **admin/probe**. Not a syzbot-
  style syscall UAF, but probe-fail is still user-visible.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record:
- Confirmed: `WARN_ON` in `cfg80211_dev_free()` if work remains queued
  (taint; panic if `panic_on_warn`).
- Author/prior commit (`4f7a077`): work running after
  `ieee80211_free_hw` is **UAF**. cfg80211’s `cancel_work_sync` in
  `cfg80211_dev_free` reduces but does not make the WARN or the post-
  unlock race imaginary (`cfg80211_wiphy_work` can run after
  `wiphy_unlock` and before free).
- Severity: **HIGH** (WARN + realistic UAF race on probe fail / unload).

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- Benefit: **high** for IWLMLD users — stops WARN/UAF on fw init failure
  and stop.
- Risk: **very low** — 3 lines, existing API, lock already held.
- Ratio: strongly in favor of including the fix.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real teardown bug: pending `async_handlers_wk` after wiphy free
- Regression from `59a5876e474ac` (in this tree); restores cancel only
  where memory is freed
- Same UAF class as `4f7a07791944e` (explicit “access freed memory”)
- 3-line, obviously correct, maintainer Reviewed-by
- Applies to this tree’s MLD code; prerequisites present
- cfg80211 documents leftover work with WARN_ON

AGAINST:
- No Fixes:/Cc:stable/Reported-by (not a negative per pipeline rules)
- Error/teardown path, not hot datapath
- cfg80211 already `cancel_work_sync`s, so many hits are WARN rather
  than a guaranteed oops
- 08/15 series member (but standalone)

UNRESOLVED:
- Full lore review text (HTTP 403)
- Whether stable@ already discussed this subject
- How often start-fail hits with work still queued (depends on
  notifications after ALIVE)

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — lock already held; Johannes
   reviewed; cancel is the documented API.
2. Fixes a real bug that affects users? **PASS** — leftover wiphy work
   on fw-start failure and op-mode stop.
3. Important issue? **PASS** — UAF risk + `WARN_ON` in cfg80211 (HIGH).
4. Small and contained? **PASS** — +3 lines, one file, two call sites.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS** — MLD + `wiphy_work_cancel` +
   matching functions exist (commit already in 7.3-rc4).

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: Not a device-ID/quirk/DT/build/docs exception. Ordinary small
bugfix.

**Step 9.4: MAKE YOUR DECISION**

This tree is **7.3-rc4** and contains the iwlwifi MLD op-mode. The hole
is real here: after `59a5876e474ac`, start-fail and stop free the wiphy
without cancelling `async_handlers_wk`. That is a use-after-free/WARN
class bug on firmware load failure — a path users hit. The fix is three
lines, matches cfg80211’s contract, and does not need the rest of the
15-patch series.

---

### What the commit solves
On MLD op-mode start, firmware can ALIVE and queue `async_handlers_wk`.
Failure then purges the handler list in `iwl_mld_stop_fw()` but leaves
the wiphy work queued. `ieee80211_free_hw()` then frees that memory.
cfg80211 still `cancel_work_sync`s and **WARNs**; there is also a window
after `wiphy_unlock` where the worker can run. The same missing cancel
exists in `iwl_op_mode_mld_stop`. Cancelling under the wiphy lock closes
that.

### Stable rules
Meets all six criteria for **this** tree: small, correct, no new API,
real WARN/UAF, code present.

### Risk vs benefit
Benefit high for Intel MLD hardware; risk very low (idempotent cancel,
lock already held).

### Concerns
None that block inclusion. Not a dependent series member. NVM-fail still
does not `iwl_mld_stop_fw()` (pre-existing); this patch still improves
that path by not leaving work queued.

Verification:
- [Phase 1] Parsed subject/tags: Reviewed-by Johannes Berg; Link to v2
  msgid; no Fixes/Cc:stable/Reported-by
- [Phase 1] Body: purge-without-cancel on start-fail and stop; work vs
  freed wiphy; cfg80211 WARN
- [Phase 2] Diff: +3 lines in `mld.c`; `iwl_op_mode_mld_start` error
  path and `iwl_op_mode_mld_stop`; `wiphy_work_cancel`
- [Phase 2] `wiphy_work_cancel()` in `net/wireless/core.c` requires
  wiphy mutex; both sites already `wiphy_lock`
- [Phase 2] `cfg80211_dev_free()`:
  `WARN_ON(!list_empty(&rdev->wiphy_work_list))` then `cancel_work_sync`
- [Phase 3] `git describe HEAD`: v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion` 7.3.0-rc4
- [Phase 3] `git merge-base --is-ancestor c99bc4d4e0ba6 HEAD` → yes
- [Phase 3] `git blame` start-fail/stop: skeleton `d1e879ec600f9` (MLD
  intro); cancel lines this commit
- [Phase 3] MLD first in v6.15 (`git merge-base --is-ancestor
  d1e879ec600f9 v6.15`); not in v6.14
- [Phase 3] `git show 59a5876e474ac`: removed `wiphy_work_cancel` from
  `iwl_mld_cancel_async_notifications`; in v7.2, not v7.1
- [Phase 3] `git show 4f7a07791944e`: original UAF fix on start-fail;
  Fixes: d1e879ec600f9
- [Phase 3] `git log -S wiphy_work_cancel -- mld/`: d1e879ec, 4f7a077,
  833026, 59a5876, c99bc4d4
- [Phase 3] Parent of candidate is unrelated mvm change; series 08/15 is
  a mixed iwlwifi-next batch
- [Phase 4] `b4 dig -c`: lore/patchwork msgid for 08/15; `-a`: v1 then
  v2 (applied); `-w`: Johannes + linux-wireless
- [Phase 4] WebFetch lore 403; patchwork bot wall; spinics 500 — review
  comments UNVERIFIED
- [Phase 4] No stable@ hit for this subject (search not useful)
- [Phase 5] `iwl_mld_ops.start` = `iwl_op_mode_mld_start`; RX path
  `wiphy_work_queue(&mld->async_handlers_wk)` in `notif.c`
- [Phase 5] `iwl_mld_load_fw` error after init sequence calls
  `iwl_mld_stop_fw` (purge, no cancel)
- [Phase 5] MVM `iwl_mvm_mac_stop` already cancels analogous wiphy work
- [Phase 6] Local `mld.c` already has both cancel sites; pre-image of
  parent matches the candidate diff
- [Phase 7] CONFIG_IWLMLD in
  `drivers/net/wireless/intel/iwlwifi/Kconfig`
- [Phase 8] Trigger: fw load fail after ALIVE / op-mode stop; severity
  HIGH (WARN + UAF race)
- UNVERIFIED: exact lore review discussion text; field frequency of this
  WARN

**YES**

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

diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mld.c b/drivers/net/wireless/intel/iwlwifi/mld/mld.c
index cf003a4a37408..49fcbe6814677 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mld.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mld.c
@@ -440,6 +440,8 @@ iwl_op_mode_mld_start(struct iwl_trans *trans, const struct iwl_rf_cfg *cfg,
 	}
 
 	if (ret) {
+		/* wiphy memory is about to be freed, we should cancel any pending work */
+		wiphy_work_cancel(mld->wiphy, &mld->async_handlers_wk);
 		wiphy_unlock(mld->wiphy);
 		rtnl_unlock();
 		goto err;
@@ -505,6 +507,7 @@ iwl_op_mode_mld_stop(struct iwl_op_mode *op_mode)
 	iwl_mld_thermal_exit(mld);
 
 	wiphy_lock(mld->wiphy);
+	wiphy_work_cancel(mld->wiphy, &mld->async_handlers_wk);
 	iwl_mld_low_latency_stop(mld);
 	iwl_mld_deinit_time_sync(mld);
 	wiphy_unlock(mld->wiphy);
-- 
2.53.0