linux-kernel - [REGRESSION] mac80211 crash in ieee80211_txq_purge() on i.MX8MP with rsi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID:
 <AM6PR04MB613698263FB5DCC7CB79BE21A6F3A@AM6PR04MB6136.eurprd04.prod.outlook.com>
Date: Wed, 22 Oct 2025 13:35:39 +0000
From: Radenovic Goran <gradenovic@...ratronik.de>
To: "marek.vasut@...lbox.org" <marek.vasut@...lbox.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"kvalo@...nel.org" <kvalo@...nel.org>, "johannes@...solutions.net"
	<johannes@...solutions.net>, "davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org"
	<kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>
CC: Kranz Christian <ckranz@...ratronik.de>, Thoma Alexander
	<athoma@...ratronik.de>, "alexander_thoma@....de" <alexander_thoma@....de>
Subject: [REGRESSION] mac80211 crash in ieee80211_txq_purge() on i.MX8MP with
 rsi_91x (6.6.88, OK in 6.6.59)

Hi, (sorry for previous e-mails, I am dealing with plain-text issue)

I’m seeing a reproducible kernel panic during Wi-Fi interface teardown on 
an NXP i.MX8M Plus based board when using the in-kernel rsi_91x (RS9116 
SDIO) driver with Linux 6.6.88. The same device and setup do not crash 
on 6.6.59. The crash happens inside mac80211 while purging iTXQ on ip 
link set wlan0 down.
This looks like a teardown race in the new ieee80211_txq_purge() path added in
6.6.y after 6.6.59.

Summary

- Kernel: 6.6.88 (stable)
- Good: 6.6.59 (stable)
- Arch/SoC: arm64, NXP i.MX8MP
- Wi-Fi: Silicon Labs RS9116 (SDIO), in-tree rsi_91x driver
- mac80211/cfg80211: in-tree (no out-of-tree patches)
- Repro: ip link set wlan0 down while associated (e.g., after connecting with NetworkManager)
- Result: Oops in fq_flow_reset() called by ieee80211_txq_purge() in ieee80211_do_stop()
- Expected: interface shuts down cleanly without oops

Crash (excerpt)

Unable to handle kernel paging request at virtual address 000000000610e020
Internal error: Oops: 0000000096000004 [#1] SMP
CPU: 3 PID: 334 Comm: ip Not tainted 6.6.88-stable-standard #1
pc : fq_flow_reset.constprop.0+0x2c/0x130 [mac80211]
lr : ieee80211_txq_purge+0x68/0x1e0 [mac80211]
Call trace:
  fq_flow_reset.constprop.0+0x2c/0x130 [mac80211]
  ieee80211_txq_purge+0x68/0x1e0 [mac80211]
  ieee80211_do_stop+0x50c/0xa38 [mac80211]
  ieee80211_stop+0x50/0x190 [mac80211]
  __dev_close_many+0xb4/0x158
  __dev_change_flags+0x19c/0x2c8
  dev_change_flags+0x28/0x78
  do_setlink+0x288/0xf30
  rtnl_newlink+0x54/0x88
...

I can share full dmesg, .config, if needed.

Reproducer
- Boot 6.6.88 on i.MX8MP with RS9116 (SDIO) using in-tree rsi_91x.
- Bring up Wi-Fi with NetworkManager (associate with any AP).
- Run ip link set wlan0 down.
- Kernel oops as above (panic shortly after).

Notes / Control experiment

On a STM32MP157 based board with the same kernel (6.6.88) and RS9116 
SDIO, I cannot reproduce the crash—teardown completes ok. This suggests a
timing-sensitive race rather than bad data or firmware.
On 6.6.59 (i.MX8MP) I also cannot reproduce—so this appears to be a regression between 6.6.59 and 6.6.88.
In net/mac80211/iface.c, newer 6.6.y contains:

    if (sdata->vif.txq)
        ieee80211_txq_purge(sdata->local, to_txq_info(sdata->vif.txq));

which was not present at the time we were running 6.6.59. The panic occurs on that purge path.

Driver specifics (rsi_91x)

The in-tree rsi_91x advertises .wake_tx_queue = 
ieee80211_handle_wake_tx_queue in ieee80211_ops but does not implement 
its own iTXQ dequeue handler.

As a cross-check, the Silicon Labs vendor driver (recent release for 
6.6, which uses its own queuing/teardown) does not crash on this 
platform with the same kernel. That again points to an ordering/teardown
issue in the mac80211 iTXQ purge path interacting with in-tree rsi_91x.

Hypothesis

A teardown race: during .stop, mac80211 purges sdata->vif.txq while 
something (either mac80211 helper or driver timing) still holds or races
with the iTXQ state, resulting in an invalid pointer deref in 
fq_flow_reset(). The fact it is easy to hit on i.MX8MP and not on 
STM32MP suggests a small timing window.
Even though rsi_91x doesn’t call ieee80211_next_txq() itself, simply 
enabling iTXQ in mac80211 (vif.txq exists) plus the purge call seems to 
be enough to expose the race on this SoC.

Best regards and thanks!

Goran Rađenović

Ultratronik GmbH
Dornierstraße 9
82205 Gilching
Germany

www.ux-gruppe.de

Geschäftsführer:
Dipl.-Kfm. Alexander Sorg, Dipl-Kfm. Alexander W. Jonke
Sitz der Gesellschaft: Gilching bei München
Registergericht München HRB 55584