[PATCH] wifi: mt76: mt7925: fix NULL dereference in CSA worker

[PATCH] wifi: mt76: mt7925: fix NULL dereference in CSA worker

[Gris Ge]

`mt7925_csa_work()` checks `dev->new_ctx` before taking `dev->mt76.mutex`,
but the pointer is re-read and dereferenced after
`mt792x_mutex_acquire()`. That check and the later use are not serialized
against a concurrent teardown, which can clear the pointer in between:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  RIP: 0010:mt7925_csa_work+0x83/0x160 [mt7925_common]
  RAX: 0000000000000000

`mt7925_remove_chanctx()` clears `dev->new_ctx` without synchronization
against the worker. During a channel switch mac80211 frees the reserved
channel context (calling `drv_remove_chanctx()`) before
`drv_abort_channel_switch()`/unassign can cancel the worker, so it can run
with a context that was just cleared.

`mt7925_channel_switch_rx_beacon()` is serialized with the writers by the
wiphy mutex; the worker is not.

Protect `dev->new_ctx` with `dev->mt76.mutex` in add_chanctx() and
remove_chanctx(), and validate it under the lock in `mt7925_csa_work()`.
Keep a local pointer for both firmware calls so the context can neither
become NULL nor be freed while it is being used.

Reproduced the panic by injecting CSA-less "abort" beacon, works well
after patched.

Fixes: 7900da40e315 ("wifi: mt76: mt7925: introduce CSA support in non-MLO mode")
Cc: stable@vger.kernel.org # 7.1+
Signed-off-by: Gris Ge <cnfourt@gmail.com>
---
 .../net/wireless/mediatek/mt76/mt7925/main.c  | 30 +++++++++++--------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 15d95ad32636..fb5f9aa3534d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -2020,7 +2020,9 @@ mt7925_add_chanctx(struct ieee80211_hw *hw,
 {
 	struct mt792x_dev *dev = mt792x_hw_dev(hw);
 
+	mutex_lock(&dev->mt76.mutex);
 	dev->new_ctx = ctx;
+	mutex_unlock(&dev->mt76.mutex);
 
 	return 0;
 }
@@ -2031,9 +2033,10 @@ mt7925_remove_chanctx(struct ieee80211_hw *hw,
 {
 	struct mt792x_dev *dev = mt792x_hw_dev(hw);
 
+	mutex_lock(&dev->mt76.mutex);
 	if (dev->new_ctx == ctx)
 		dev->new_ctx = NULL;
-
+	mutex_unlock(&dev->mt76.mutex);
 }
 
 static void
@@ -2509,11 +2512,13 @@ static int mt7925_switch_vif_chanctx(struct ieee80211_hw *hw,
 
 void mt7925_csa_work(struct work_struct *work)
 {
+	struct ieee80211_chanctx_conf *ctx;
 	struct mt792x_vif *mvif;
 	struct mt792x_dev *dev;
 	struct ieee80211_vif *vif;
 	struct ieee80211_bss_conf *link_conf;
 	struct mt792x_bss_conf *mconf;
+	bool roc_started;
 	u8 link_id, roc_rtype;
 	int ret = 0;
 
@@ -2525,26 +2530,27 @@ void mt7925_csa_work(struct work_struct *work)
 	if (ieee80211_vif_is_mld(vif))
 		return;
 
-	if (!dev->new_ctx)
-		return;
-
 	link_id = 0;
 	mconf = &mvif->bss_conf;
 	link_conf = &vif->bss_conf;
 	roc_rtype = MT7925_ROC_REQ_JOIN;
 
 	mt792x_mutex_acquire(dev);
-	ret = mt7925_set_roc(mvif->phy, mconf, dev->new_ctx->def.chan,
-			     4000, roc_rtype);
-	mt792x_mutex_release(dev);
-	if (!ret) {
-		mt792x_mutex_acquire(dev);
-		ret = mt7925_mcu_set_chctx(mvif->phy->mt76, &mconf->mt76, link_conf,
-					   dev->new_ctx);
+	ctx = dev->new_ctx;
+	if (!ctx) {
 		mt792x_mutex_release(dev);
+		return;
+	}
 
+	ret = mt7925_set_roc(mvif->phy, mconf, ctx->def.chan, 4000, roc_rtype);
+	roc_started = !ret;
+	if (!ret)
+		ret = mt7925_mcu_set_chctx(mvif->phy->mt76, &mconf->mt76, link_conf,
+					   ctx);
+	mt792x_mutex_release(dev);
+
+	if (roc_started)
 		mt7925_abort_roc(mvif->phy, mconf);
-	}
 
 	ieee80211_chswitch_done(vif, !ret, link_id);
 }
-- 
2.56.0

Re: [PATCH] wifi: mt76: mt7925: fix NULL dereference in CSA worker

[Andreas Haerter]

On Sun, Oct 25, 2026 at 10:01:18PM +0800, Gris Ge wrote:
> Reproduced the panic by injecting CSA-less "abort" beacon, works well
> after patched.

I hit the same oops in normal use, with no injected frames, on a
ThinkPad X13 Gen 6 (MT7925, 14c3:7925) running Fedora's
7.2.14-200.fc44.x86_64, not tainted:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  Workqueue: phy0 mt7925_csa_work [mt7925_common]
  RIP: 0010:mt7925_csa_work+0x83/0x160 [mt7925_common]
  RAX: 0000000000000000 RBX: ffff8eeb5bbb3910 RCX: 0000000000000fa0

The code bytes decode to the dev->new_ctx load followed by the read of
def.chan for mt7925_set_roc(), and RCX holds the duration of 4000.

The access point announced a channel switch just after a roam:

  10:58:02.90  associated with the new BSS on 5180 MHz
  10:58:04.05  CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5180 (80 MHz)
  10:58:04.47  oops

It has happened once. Two earlier channel switches on this machine
completed normally, and the log does not show what tore the context
down.

The impact MAY be worth a line in the changelog. The oops lands between
mt792x_mutex_acquire() and the release, so dev->mt76.mutex stays held
for good. WiFi did not come back, and at shutdown wpa_supplicant,
NetworkManager, avahi-daemon and systemd-resolved all survived SIGKILL.
The machine needed a forced power-off, so the stable tag looks right to
me.

I read the patch against master and v7.2.14. The chanctx hunks apply to
v7.2.14 with an offset and mt7925_csa_work() is identical there. I see
no new lock ordering problem.

I have no reproducer, so I cannot offer a Tested-by.

Thanks,
Andreas

-- 
foundata GmbH
Steinhäuserstr. 20
76135 Karlsruhe


Web: https://foundata.com
Sitz der Gesellschaft: Karlsruhe
Registergericht: Amtsgericht Mannheim, HRB 714807
Geschäftsführung: Andreas Haerter
USt-IdNr.: DE284122682