[PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[傅继晗]

Commit 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
removed the fallback path in ieee80211_monitor_start_xmit() for when
the monitor interface has no channel context assigned. This broke frame
capture and injection for drivers that implement real channel context
ops (as opposed to the ieee80211_emulate_* helpers), such as the mt76
family, when a monitor interface runs alongside another interface
(e.g. managed mode).

In that scenario the (virtual) monitor sdata does not get a chanctx of
its own, even though there is an active one from the other interface.
Before the simplification the code fell back to local->_oper_chandef;
after it, the code goes straight to fail_rcu and silently drops every
injected frame.

Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
behaviour") restored the fallback for drivers using emulate_chanctx,
but explicitly left real chanctx drivers unfixed.

Fix this by falling back to the first entry in local->chanctx_list
when the monitor vif has no chanctx and the driver uses real channel
contexts. This is analogous to how ieee80211_hw_conf_chan() already
uses the same pattern.

Tested on MT7921AU (mt76) USB adapter:
  - v6.13: managed + monitor coexistence restored (0 -> 37 frames/5s)
  - v6.19: managed + monitor coexistence restored (0 -> 39 frames/5s)
  - v7.0-rc2: managed + monitor coexistence restored (0 -> 33 frames/5s)

Cc: stable@vger.kernel.org
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Link: https://github.com/morrownr/USB-WiFi/issues/682
Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
---
 net/mac80211/tx.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 8cdbd41..56eaf9a 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2396,12 +2396,28 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 				rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
 	}
 
-	if (chanctx_conf)
+	if (chanctx_conf) {
 		chandef = &chanctx_conf->def;
-	else if (local->emulate_chanctx)
+	} else if (local->emulate_chanctx) {
 		chandef = &local->hw.conf.chandef;
-	else
-		goto fail_rcu;
+	} else {
+		/*
+		 * For real chanctx drivers (e.g. mt76), the monitor
+		 * interface may not have a chanctx assigned when running
+		 * concurrently with another interface. Fall back to any
+		 * active chanctx so that injection can still work on the
+		 * operating channel.
+		 */
+		struct ieee80211_chanctx *ctx;
+
+		ctx = list_first_entry_or_null(&local->chanctx_list,
+					       struct ieee80211_chanctx,
+					       list);
+		if (ctx)
+			chandef = &ctx->conf.def;
+		else
+			goto fail_rcu;
+	}
 
 	/*
 	 * If driver/HW supports IEEE80211_CHAN_CAN_MONITOR we still
-- 
2.43.0

Re: [PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

On Sun, 2026-03-08 at 16:45 +0000, 傅继晗 wrote:
> Commit 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
> removed the fallback path in ieee80211_monitor_start_xmit() for when
> the monitor interface has no channel context assigned. This broke frame
> capture and injection for drivers that implement real channel context
> ops (as opposed to the ieee80211_emulate_* helpers), such as the mt76
> family, when a monitor interface runs alongside another interface
> (e.g. managed mode).

It actually broke the others too, as you note later.

> In that scenario the (virtual) monitor sdata does not get a chanctx of
> its own, even though there is an active one from the other interface.
> Before the simplification the code fell back to local->_oper_chandef;
> after it, the code goes straight to fail_rcu and silently drops every
> injected frame.
> 
> Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
> behaviour") restored the fallback for drivers using emulate_chanctx,
> but explicitly left real chanctx drivers unfixed.
> 
> Fix this by falling back to the first entry in local->chanctx_list
> when the monitor vif has no chanctx and the driver uses real channel
> contexts. This is analogous to how ieee80211_hw_conf_chan() already
> uses the same pattern.

I did have pretty much the same attempt at a fix:

https://lore.kernel.org/linux-wireless/20251216111909.25076-2-johannes@sipsolutions.net/

but it was reported to cause crashes on certain devices, so we didn't
think it was very safe at the time.

Is that no longer an issue?

johannes

Re: [PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[傅继晗]

On Sun, 2026-03-08 at 16:45 +0000, 傅继晗 wrote:
> Fix this by falling back to the first entry in local->chanctx_list
> when the monitor vif has no chanctx and the driver uses real channel
> contexts. This is analogous to how ieee80211_hw_conf_chan() already
> uses the same pattern.

On Mon, 2026-03-09, Johannes Berg wrote:
> I did have pretty much the same attempt at a fix:
> https://lore.kernel.org/linux-wireless/20251216111909.25076-2-johannes@sipsolutions.net/
>
> but it was reported to cause crashes on certain devices, so we didn't
> think it was very safe at the time.
>
> Is that no longer an issue?

Hi Johannes,

Thanks for the quick review and for pointing me to your earlier v2
patch.

I see the key difference between our approaches: your v2 iterates
the chanctx_list and only proceeds when there is exactly one entry
(going to fail_rcu if more than one exists), while mine blindly takes
the first entry via list_first_entry_or_null(). Your approach is
clearly safer -- in a multi-chanctx scenario, there is no way to know
which channel the user intends to inject on, so refusing is the
correct behaviour.

I have tested my patch on an MT7921AU (mt76, USB) adapter across
v6.13, v6.19, and v7.0-rc2 with managed + monitor coexistence, and
have not observed any crashes. However, my testing was limited to a
single-chanctx scenario (one managed interface + one monitor
interface), so it does not rule out crashes in multi-chanctx
configurations.

Could you share some details about the crashes that were reported
with your v2? For example, which devices/drivers were affected and
what the crash signature looked like? That would help me understand
whether the issue was specific to multi-chanctx usage or something
more fundamental with accessing the chanctx_list in this code path.

If you agree, I would like to send a v2 that combines both approaches:
use list_first_entry_or_null() for simplicity, but add a
list_is_singular() guard so we only proceed when there is exactly one
chanctx -- matching the safety constraint from your v2:

--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2399,10 +2399,24 @@
-	if (chanctx_conf)
+	if (chanctx_conf) {
 		chandef = &chanctx_conf->def;
-	else if (local->emulate_chanctx)
+	} else if (local->emulate_chanctx) {
 		chandef = &local->hw.conf.chandef;
-	else
-		goto fail_rcu;
+	} else {
+		struct ieee80211_chanctx *ctx;
+
+		ctx = list_first_entry_or_null(&local->chanctx_list,
+					       struct ieee80211_chanctx,
+					       list);
+		if (ctx && list_is_singular(&local->chanctx_list))
+			chandef = &ctx->conf.def;
+		else
+			goto fail_rcu;
+	}

This avoids the ambiguity of picking an arbitrary chanctx in
multi-chanctx scenarios while still fixing the common single-chanctx
case (e.g. one managed + one monitor interface).

Alternatively, if you would prefer to revive your own patch, I am
happy to help test it on mt76 hardware.

Thanks,
Jihan

Re: [PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

On Mon, 2026-03-09 at 10:45 +0000, 傅继晗 wrote:
> 
> I see the key difference between our approaches: your v2 iterates
> the chanctx_list and only proceeds when there is exactly one entry
> (going to fail_rcu if more than one exists), while mine blindly takes
> the first entry via list_first_entry_or_null(). Your approach is
> clearly safer -- in a multi-chanctx scenario, there is no way to know
> which channel the user intends to inject on, so refusing is the
> correct behaviour.

Oh, right, I hadn't even realised that at first.

> I have tested my patch on an MT7921AU (mt76, USB) adapter across
> v6.13, v6.19, and v7.0-rc2 with managed + monitor coexistence, and
> have not observed any crashes. However, my testing was limited to a
> single-chanctx scenario (one managed interface + one monitor
> interface), so it does not rule out crashes in multi-chanctx
> configurations.

Maybe Óscar can comment on which device/version he tested and got the
crash with? I just would like to avoid having crashes because of this,
but generally think that - perhaps optionally - we could have code like
this, since people _do_ want injection to work.

> Could you share some details about the crashes that were reported
> with your v2? For example, which devices/drivers were affected and
> what the crash signature looked like? That would help me understand
> whether the issue was specific to multi-chanctx usage or something
> more fundamental with accessing the chanctx_list in this code path.

No, it was specific to some driver implementation, but I don't have any
more information now.

> If you agree, I would like to send a v2 that combines both approaches:
> use list_first_entry_or_null() for simplicity, but add a
> list_is_singular() guard so we only proceed when there is exactly one
> chanctx -- matching the safety constraint from your v2:
> 
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -2399,10 +2399,24 @@
> -	if (chanctx_conf)
> +	if (chanctx_conf) {
>  		chandef = &chanctx_conf->def;
> -	else if (local->emulate_chanctx)
> +	} else if (local->emulate_chanctx) {
>  		chandef = &local->hw.conf.chandef;
> -	else
> -		goto fail_rcu;
> +	} else {
> +		struct ieee80211_chanctx *ctx;
> +
> +		ctx = list_first_entry_or_null(&local->chanctx_list,
> +					       struct ieee80211_chanctx,
> +					       list);
> +		if (ctx && list_is_singular(&local->chanctx_list))
> +			chandef = &ctx->conf.def;
> +		else
> +			goto fail_rcu;
> +	}
> 
> This avoids the ambiguity of picking an arbitrary chanctx in
> multi-chanctx scenarios while still fixing the common single-chanctx
> case (e.g. one managed + one monitor interface).

Seems reasonable, I think we could even drop the "if (emulate) part
(since in that case the list should always be singular). Just like I
said above - would like to understand the issue that had appeared with
it.

johannes

Re: [PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Óscar Alfonso Díaz]

Hi, I've sent earlier an email to show on screenshots the results of
my testing but it was rejected as the email distribution lists just
support plaintext emails. So I'm sending it again this time explaining
the results without the visual proof.

 I was testing this patch using Mediatek MT7921U chipset:

https://lore.kernel.org/linux-wireless/20260308164510.5927-1-fjhhz1997@gmail.com/raw

It didn't work properly. The test consisted in split the Mediatek
adapter into two adapters (enabling VIF), and then try injection using
a test aireplay command:

iw phy phy3 interface add mon0 type monitor
ip link set mon0 up
aireplay-ng -9

Apart of that test, I also tested it creating an Evil Twin attack
using VIF feature and trying DoS at the same time as creating an AP.
On Mediatek, with the patched kernel, the test resulted in a totally
hang of the Kali VM

Let me know if I can help further or test another patch.

Thanks and regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--


El jue, 19 mar 2026 a las 12:30, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Hello, I was testing this patch using Mediatek MT7921U chipset:
>
> https://lore.kernel.org/linux-wireless/20260308164510.5927-1-fjhhz1997@gmail.com/raw
>
> It didn't work properly:
>
>
>
> As you know, expected result is like this:
>
>
>
> Note the difference from the first screenshot, kernel is custom compiled 6.18.12 and the second one is the default kali linux 6.18.12 (6.18.12+kali-amd64) and using a non-Mediatek chipset to show that how it should be when it works correctly.
>
> Apart of the test of the screenshots, I also tested it creating an Evil Twin attack using VIF feature and trying DoS at the same time as creating an AP. On Mediatek, with the patched kernel, the test resulted in a totally hang of the Kali VM
>
> Let me know if I can help further or test another patch.
>
> Thanks and regards.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 || https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
>
>
> El lun, 16 mar 2026 a las 11:38, Johannes Berg (<johannes@sipsolutions.net>) escribió:
>>
>> On Mon, 2026-03-09 at 10:45 +0000, 傅继晗 wrote:
>> >
>> > I see the key difference between our approaches: your v2 iterates
>> > the chanctx_list and only proceeds when there is exactly one entry
>> > (going to fail_rcu if more than one exists), while mine blindly takes
>> > the first entry via list_first_entry_or_null(). Your approach is
>> > clearly safer -- in a multi-chanctx scenario, there is no way to know
>> > which channel the user intends to inject on, so refusing is the
>> > correct behaviour.
>>
>> Oh, right, I hadn't even realised that at first.
>>
>> > I have tested my patch on an MT7921AU (mt76, USB) adapter across
>> > v6.13, v6.19, and v7.0-rc2 with managed + monitor coexistence, and
>> > have not observed any crashes. However, my testing was limited to a
>> > single-chanctx scenario (one managed interface + one monitor
>> > interface), so it does not rule out crashes in multi-chanctx
>> > configurations.
>>
>> Maybe Óscar can comment on which device/version he tested and got the
>> crash with? I just would like to avoid having crashes because of this,
>> but generally think that - perhaps optionally - we could have code like
>> this, since people _do_ want injection to work.
>>
>> > Could you share some details about the crashes that were reported
>> > with your v2? For example, which devices/drivers were affected and
>> > what the crash signature looked like? That would help me understand
>> > whether the issue was specific to multi-chanctx usage or something
>> > more fundamental with accessing the chanctx_list in this code path.
>>
>> No, it was specific to some driver implementation, but I don't have any
>> more information now.
>>
>> > If you agree, I would like to send a v2 that combines both approaches:
>> > use list_first_entry_or_null() for simplicity, but add a
>> > list_is_singular() guard so we only proceed when there is exactly one
>> > chanctx -- matching the safety constraint from your v2:
>> >
>> > --- a/net/mac80211/tx.c
>> > +++ b/net/mac80211/tx.c
>> > @@ -2399,10 +2399,24 @@
>> > -     if (chanctx_conf)
>> > +     if (chanctx_conf) {
>> >               chandef = &chanctx_conf->def;
>> > -     else if (local->emulate_chanctx)
>> > +     } else if (local->emulate_chanctx) {
>> >               chandef = &local->hw.conf.chandef;
>> > -     else
>> > -             goto fail_rcu;
>> > +     } else {
>> > +             struct ieee80211_chanctx *ctx;
>> > +
>> > +             ctx = list_first_entry_or_null(&local->chanctx_list,
>> > +                                            struct ieee80211_chanctx,
>> > +                                            list);
>> > +             if (ctx && list_is_singular(&local->chanctx_list))
>> > +                     chandef = &ctx->conf.def;
>> > +             else
>> > +                     goto fail_rcu;
>> > +     }
>> >
>> > This avoids the ambiguity of picking an arbitrary chanctx in
>> > multi-chanctx scenarios while still fixing the common single-chanctx
>> > case (e.g. one managed + one monitor interface).
>>
>> Seems reasonable, I think we could even drop the "if (emulate) part
>> (since in that case the list should always be singular). Just like I
>> said above - would like to understand the issue that had appeared with
>> it.
>>
>> johannes

Re: [PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[傅继晗]

Hi Oscar,

Thank you for testing the v1 patch and reporting the VM hang -- your
report was critical in identifying the root cause.

Lucid-Duck did extensive debugging and reproduction work on this.
The full discussion is here:
https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4120751621

Root cause of the crash:

The v1 patch falls back to list_first_entry_or_null(&local->chanctx_list)
when the monitor vif has no chanctx. In your Evil Twin + DoS scenario,
the AP and monitor interfaces created multiple channel contexts. The
fallback blindly grabbed whichever chanctx was first on the list --
which could be the AP's chanctx that the firmware wasn't expecting
monitor traffic on. Injecting frames on a chanctx where
mt7921_mcu_config_sniffer() was never called is the likely trigger
for the hard hang.

The v2 patch adds a list_is_singular() guard: injection only proceeds
when there is exactly one chanctx (unambiguous), and is refused when
multiple chanctxs exist. This covers the common single-channel AP +
monitor case while preventing the dangerous multi-chanctx path that
caused your crash.

Lucid-Duck tested v2 extensively on kernel 6.19.8 with the MT7921AU
(ALFA AWUS036AXML) -- single-channel AP + monitor + injection,
multi-chanctx via P2P-GO, heavy load injection floods (50k fps,
1.8M packets) -- all stable with zero crashes or kernel warnings.

The v2 diff against net/mac80211/tx.c:

 	chanctx_conf = rcu_dereference(sdata->vif.bss_conf.chanctx_conf);
-	if (chanctx_conf)
+	if (chanctx_conf) {
 		chandef = &chanctx_conf->def;
-	else if (local->emulate_chanctx)
+	} else if (local->emulate_chanctx) {
 		chandef = &local->hw.conf.chandef;
-	else
-		goto fail_rcu;
+	} else {
+		struct ieee80211_chanctx *ctx;
+
+		ctx = list_first_entry_or_null(&local->chanctx_list,
+					       struct ieee80211_chanctx,
+					       list);
+		if (ctx && list_is_singular(&local->chanctx_list))
+			chandef = &ctx->conf.def;
+		else
+			goto fail_rcu;
+	}

If you have time, could you re-test with this v2 patch in your
original Evil Twin + DoS setup? That would help confirm the fix
before I send v2 to the list.

Thanks again for your help!

Best regards,
傅继晗

Re: [PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Óscar Alfonso Díaz]

Hello everybody. I've tested this patch and I'm sorry to say this...
but, bad news. Same behaviour. I mean, as soon as the DoS window
appears during the evil twin attack, the VM is completely frozen.

I put the full report including screenshots on the github thread:
https://github.com/morrownr/USB-WiFi/issues/682

If you are interested in reproducing what I do, it is pretty simple.
You just need linux, one wireless adapter using an affected by the bug
Mediatek chipset (in my case chipset is MT7921U, also tested on
MT7921AUN), a wireless network and a client connected (your mobile
phone is enough). Use the airgeddon tool and launch the most simple
evil twin attack over it:

git clone https://github.com/v1s1t0r1sh3r3/airgeddon
cd airgeddon
bash airgeddon.sh
Navigate through menus selecting the Mediatek adapter, then evil twin
menu (option 7) and then scan for your target network (option 4).
After selecting it, Just launch the "Evil Twin attack just AP" (option
5) and wait until all the 4 windows of the attack appear, then check
if your client (mobile phone) is disconnected from the network. That's
it.

In my case, just 3 windows opened... the first one is the Fake AP, the
second is a DHCP server, the third one is the DoS window, and as I
said, as soon as it appears, everything hangs... so no time for the
4th window to be opened (the control window).

Kind regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El mié, 25 mar 2026 a las 1:15, 傅继晗 (<fjhhz1997@gmail.com>) escribió:
>
> Hi Oscar,
>
> Thank you for testing the v1 patch and reporting the VM hang -- your
> report was critical in identifying the root cause.
>
> Lucid-Duck did extensive debugging and reproduction work on this.
> The full discussion is here:
> https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4120751621
>
> Root cause of the crash:
>
> The v1 patch falls back to list_first_entry_or_null(&local->chanctx_list)
> when the monitor vif has no chanctx. In your Evil Twin + DoS scenario,
> the AP and monitor interfaces created multiple channel contexts. The
> fallback blindly grabbed whichever chanctx was first on the list --
> which could be the AP's chanctx that the firmware wasn't expecting
> monitor traffic on. Injecting frames on a chanctx where
> mt7921_mcu_config_sniffer() was never called is the likely trigger
> for the hard hang.
>
> The v2 patch adds a list_is_singular() guard: injection only proceeds
> when there is exactly one chanctx (unambiguous), and is refused when
> multiple chanctxs exist. This covers the common single-channel AP +
> monitor case while preventing the dangerous multi-chanctx path that
> caused your crash.
>
> Lucid-Duck tested v2 extensively on kernel 6.19.8 with the MT7921AU
> (ALFA AWUS036AXML) -- single-channel AP + monitor + injection,
> multi-chanctx via P2P-GO, heavy load injection floods (50k fps,
> 1.8M packets) -- all stable with zero crashes or kernel warnings.
>
> The v2 diff against net/mac80211/tx.c:
>
>         chanctx_conf = rcu_dereference(sdata->vif.bss_conf.chanctx_conf);
> -       if (chanctx_conf)
> +       if (chanctx_conf) {
>                 chandef = &chanctx_conf->def;
> -       else if (local->emulate_chanctx)
> +       } else if (local->emulate_chanctx) {
>                 chandef = &local->hw.conf.chandef;
> -       else
> -               goto fail_rcu;
> +       } else {
> +               struct ieee80211_chanctx *ctx;
> +
> +               ctx = list_first_entry_or_null(&local->chanctx_list,
> +                                              struct ieee80211_chanctx,
> +                                              list);
> +               if (ctx && list_is_singular(&local->chanctx_list))
> +                       chandef = &ctx->conf.def;
> +               else
> +                       goto fail_rcu;
> +       }
>
> If you have time, could you re-test with this v2 patch in your
> original Evil Twin + DoS setup? That would help confirm the fix
> before I send v2 to the list.
>
> Thanks again for your help!
>
> Best regards,
> 傅继晗

Re: [PATCH v2] wifi: mac80211: fix the issue of NULL pointer access when deleting the virtual interface

[傅继晗]

Hi Óscar,

Lucid-Duck spent some time trying to reproduce your crash and wasn't able
to trigger it. Here's a summary of what was tested:

- Kali 2025.4 (kernel 6.18.12+kali-amd64) VM on QEMU/KVM, with my v2
  patch applied
- MT7921AU USB adapter, passthrough to VM
- Full airgeddon evil twin flow: monitor VIF + hostapd AP + continuous
  deauth via aireplay-ng
- Also tested on bare metal Fedora 6.19.8 with the same adapter

All tests were stable -- no crash, no dmesg errors, load stayed low. The
deauth frames were confirmed sending for 30+ seconds under the v2 patch
without issues.

The one variable that couldn't be matched was the VM hypervisor.
Lucid-Duck used QEMU/KVM, which handles USB passthrough at the kernel
level (xHCI). If you're using VirtualBox or VMware, the USB passthrough
path is quite different (userspace proxy), and that could potentially
explain a total VM freeze that isn't a kernel panic.

Could you please reply to Lucid-Duck directly on GitHub with the
following information? Here's the link:
https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4129198757

1. Which hypervisor are you using? (VirtualBox, VMware, QEMU/KVM, etc.)
2. Your exact USB adapter model and ID? (0e8d:7961 covers several
   MT7921 variants)
3. If possible, try SSHing into the VM from the host while the display
   is frozen -- if SSH still works, the issue is at the hypervisor/display
   level, not the kernel.

Thanks,
傅继晗

Re: [PATCH v2] wifi: mac80211: fix the issue of NULL pointer access when deleting the virtual interface

[Óscar Alfonso Díaz]

Hi, in response to the three points:

1. VMware

2. This is the output of the lsusb command: "Bus 004 Device 002: ID
0e8d:7961 MediaTek Inc. Wireless_Device". The adapter is very cheap,
it’s a Fenvi AX1800 (MT7921U), this one:
https://s.click.aliexpress.com/e/_okxhxNl . But as I said, the bug
also happens when using the Alfa AWUS036AXML (MT7921AUN).

3. I’m not sure about this right now. I’d say everything dies. I’ll
test that to see if SSH is still available (I don’t think so, but I’m
not 100% sure at the moment).

Give me a few days. I’ll test this again over the weekend. I’ll also
run a test on bare metal (not in a VM). That said, like me, many
people use VMs for pentesting. So even if it works on bare metal,
which I’ll test this weekend, I think it would still be worth
investigating whether it can be fixed for VMs, since many people,
myself included, use them for work. If it works with other WiFi
adapters, it would be a big drawback if it didn’t work with MediaTek
adapters.

I’ll also reply with a similar message in the thread.

Thanks and regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El jue, 26 mar 2026 a las 2:37, 傅继晗 (<fjhhz1997@gmail.com>) escribió:
>
> Hi Óscar,
>
> Lucid-Duck spent some time trying to reproduce your crash and wasn't able
> to trigger it. Here's a summary of what was tested:
>
> - Kali 2025.4 (kernel 6.18.12+kali-amd64) VM on QEMU/KVM, with my v2
>   patch applied
> - MT7921AU USB adapter, passthrough to VM
> - Full airgeddon evil twin flow: monitor VIF + hostapd AP + continuous
>   deauth via aireplay-ng
> - Also tested on bare metal Fedora 6.19.8 with the same adapter
>
> All tests were stable -- no crash, no dmesg errors, load stayed low. The
> deauth frames were confirmed sending for 30+ seconds under the v2 patch
> without issues.
>
> The one variable that couldn't be matched was the VM hypervisor.
> Lucid-Duck used QEMU/KVM, which handles USB passthrough at the kernel
> level (xHCI). If you're using VirtualBox or VMware, the USB passthrough
> path is quite different (userspace proxy), and that could potentially
> explain a total VM freeze that isn't a kernel panic.
>
> Could you please reply to Lucid-Duck directly on GitHub with the
> following information? Here's the link:
> https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4129198757
>
> 1. Which hypervisor are you using? (VirtualBox, VMware, QEMU/KVM, etc.)
> 2. Your exact USB adapter model and ID? (0e8d:7961 covers several
>    MT7921 variants)
> 3. If possible, try SSHing into the VM from the host while the display
>    is frozen -- if SSH still works, the issue is at the hypervisor/display
>    level, not the kernel.
>
> Thanks,
> 傅继晗

Re: [PATCH v2] wifi: mac80211: fix the issue of NULL pointer access when deleting the virtual interface

[Óscar Alfonso Díaz]

Please review my latest messages in the GitHub thread.
https://github.com/morrownr/USB-WiFi/issues/682

There you’ll even find a link to a video I recorded so you can see
that even on bare metal with Kali Linux installed natively, it still
doesn’t work. It behaves exactly the same as it does in the VM.

Here is the link
https://www.dropbox.com/scl/fi/i6h8xbls5xkvae0pitrbg/video_2026-03-29_23-44-36.mp4?rlkey=jm48ly9tjwbhsi4aauml2auh9&dl=1

Regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El jue, 26 mar 2026 a las 13:16, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Hi, in response to the three points:
>
> 1. VMware
>
> 2. This is the output of the lsusb command: "Bus 004 Device 002: ID
> 0e8d:7961 MediaTek Inc. Wireless_Device". The adapter is very cheap,
> it’s a Fenvi AX1800 (MT7921U), this one:
> https://s.click.aliexpress.com/e/_okxhxNl . But as I said, the bug
> also happens when using the Alfa AWUS036AXML (MT7921AUN).
>
> 3. I’m not sure about this right now. I’d say everything dies. I’ll
> test that to see if SSH is still available (I don’t think so, but I’m
> not 100% sure at the moment).
>
> Give me a few days. I’ll test this again over the weekend. I’ll also
> run a test on bare metal (not in a VM). That said, like me, many
> people use VMs for pentesting. So even if it works on bare metal,
> which I’ll test this weekend, I think it would still be worth
> investigating whether it can be fixed for VMs, since many people,
> myself included, use them for work. If it works with other WiFi
> adapters, it would be a big drawback if it didn’t work with MediaTek
> adapters.
>
> I’ll also reply with a similar message in the thread.
>
> Thanks and regards.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 ||
> https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
>
> El jue, 26 mar 2026 a las 2:37, 傅继晗 (<fjhhz1997@gmail.com>) escribió:
> >
> > Hi Óscar,
> >
> > Lucid-Duck spent some time trying to reproduce your crash and wasn't able
> > to trigger it. Here's a summary of what was tested:
> >
> > - Kali 2025.4 (kernel 6.18.12+kali-amd64) VM on QEMU/KVM, with my v2
> >   patch applied
> > - MT7921AU USB adapter, passthrough to VM
> > - Full airgeddon evil twin flow: monitor VIF + hostapd AP + continuous
> >   deauth via aireplay-ng
> > - Also tested on bare metal Fedora 6.19.8 with the same adapter
> >
> > All tests were stable -- no crash, no dmesg errors, load stayed low. The
> > deauth frames were confirmed sending for 30+ seconds under the v2 patch
> > without issues.
> >
> > The one variable that couldn't be matched was the VM hypervisor.
> > Lucid-Duck used QEMU/KVM, which handles USB passthrough at the kernel
> > level (xHCI). If you're using VirtualBox or VMware, the USB passthrough
> > path is quite different (userspace proxy), and that could potentially
> > explain a total VM freeze that isn't a kernel panic.
> >
> > Could you please reply to Lucid-Duck directly on GitHub with the
> > following information? Here's the link:
> > https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4129198757
> >
> > 1. Which hypervisor are you using? (VirtualBox, VMware, QEMU/KVM, etc.)
> > 2. Your exact USB adapter model and ID? (0e8d:7961 covers several
> >    MT7921 variants)
> > 3. If possible, try SSHing into the VM from the host while the display
> >    is frozen -- if SSH still works, the issue is at the hypervisor/display
> >    level, not the kernel.
> >
> > Thanks,
> > 傅继晗

Re: [PATCH v2] wifi: mac80211: fix the issue of NULL pointer access when deleting the virtual interface

[Óscar Alfonso Díaz]

Hello everyone, a member of the airgeddon team made a kernel
modification that seems to work. I’ve tested it on VMware and also on
bare metal with a 7.0.0-rc5 kernel, using both a Fenvi AX1800
(MT7921U) and an Alfa AWUS036AXML (MT7921AUN), and it appears to work
well. Deauthentication during VIF operation (evil twin attack) is now
working for MediaTek.

Everything is documented at this comment in the GitHub thread
(https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4167080451),
including the patch used. A patch that is modifying these three files
(tx.c, chan.c and ieee80211_i.h). Take a look at it  on the Github
thread please.

Regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El dom, 29 mar 2026 a las 23:55, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Please review my latest messages in the GitHub thread.
> https://github.com/morrownr/USB-WiFi/issues/682
>
> There you’ll even find a link to a video I recorded so you can see
> that even on bare metal with Kali Linux installed natively, it still
> doesn’t work. It behaves exactly the same as it does in the VM.
>
> Here is the link
> https://www.dropbox.com/scl/fi/i6h8xbls5xkvae0pitrbg/video_2026-03-29_23-44-36.mp4?rlkey=jm48ly9tjwbhsi4aauml2auh9&dl=1
>
> Regards.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 ||
> https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
>
> El jue, 26 mar 2026 a las 13:16, Óscar Alfonso Díaz
> (<oscar.alfonso.diaz@gmail.com>) escribió:
> >
> > Hi, in response to the three points:
> >
> > 1. VMware
> >
> > 2. This is the output of the lsusb command: "Bus 004 Device 002: ID
> > 0e8d:7961 MediaTek Inc. Wireless_Device". The adapter is very cheap,
> > it’s a Fenvi AX1800 (MT7921U), this one:
> > https://s.click.aliexpress.com/e/_okxhxNl . But as I said, the bug
> > also happens when using the Alfa AWUS036AXML (MT7921AUN).
> >
> > 3. I’m not sure about this right now. I’d say everything dies. I’ll
> > test that to see if SSH is still available (I don’t think so, but I’m
> > not 100% sure at the moment).
> >
> > Give me a few days. I’ll test this again over the weekend. I’ll also
> > run a test on bare metal (not in a VM). That said, like me, many
> > people use VMs for pentesting. So even if it works on bare metal,
> > which I’ll test this weekend, I think it would still be worth
> > investigating whether it can be fixed for VMs, since many people,
> > myself included, use them for work. If it works with other WiFi
> > adapters, it would be a big drawback if it didn’t work with MediaTek
> > adapters.
> >
> > I’ll also reply with a similar message in the thread.
> >
> > Thanks and regards.
> > --
> > Oscar
> >
> > OpenPGP Key: DA9C60E9 ||
> > https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> > 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> > --
> >
> > El jue, 26 mar 2026 a las 2:37, 傅继晗 (<fjhhz1997@gmail.com>) escribió:
> > >
> > > Hi Óscar,
> > >
> > > Lucid-Duck spent some time trying to reproduce your crash and wasn't able
> > > to trigger it. Here's a summary of what was tested:
> > >
> > > - Kali 2025.4 (kernel 6.18.12+kali-amd64) VM on QEMU/KVM, with my v2
> > >   patch applied
> > > - MT7921AU USB adapter, passthrough to VM
> > > - Full airgeddon evil twin flow: monitor VIF + hostapd AP + continuous
> > >   deauth via aireplay-ng
> > > - Also tested on bare metal Fedora 6.19.8 with the same adapter
> > >
> > > All tests were stable -- no crash, no dmesg errors, load stayed low. The
> > > deauth frames were confirmed sending for 30+ seconds under the v2 patch
> > > without issues.
> > >
> > > The one variable that couldn't be matched was the VM hypervisor.
> > > Lucid-Duck used QEMU/KVM, which handles USB passthrough at the kernel
> > > level (xHCI). If you're using VirtualBox or VMware, the USB passthrough
> > > path is quite different (userspace proxy), and that could potentially
> > > explain a total VM freeze that isn't a kernel panic.
> > >
> > > Could you please reply to Lucid-Duck directly on GitHub with the
> > > following information? Here's the link:
> > > https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4129198757
> > >
> > > 1. Which hypervisor are you using? (VirtualBox, VMware, QEMU/KVM, etc.)
> > > 2. Your exact USB adapter model and ID? (0e8d:7961 covers several
> > >    MT7921 variants)
> > > 3. If possible, try SSHing into the VM from the host while the display
> > >    is frozen -- if SSH still works, the issue is at the hypervisor/display
> > >    level, not the kernel.
> > >
> > > Thanks,
> > > 傅继晗

Re: [PATCH v2] wifi: mac80211: fix the issue of NULL pointer access when deleting the virtual interface

[Óscar Alfonso Díaz]

Hello, I would like to copy Brite from the airgeddon team, who has
come up with a solution. I will include him in the email, and he will
send you a patch for you to review.

This patch has been refined after a lot of work and no longer has any
“side effects”. At least, we have not detected anything unusual, and
it has been tested extensively with many different chipsets. In any
case, it’s best if he replies to the email himself to explain it and
propose the patch.

Thanks and regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El jue, 2 abr 2026 a las 2:06, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Hello everyone, a member of the airgeddon team made a kernel
> modification that seems to work. I’ve tested it on VMware and also on
> bare metal with a 7.0.0-rc5 kernel, using both a Fenvi AX1800
> (MT7921U) and an Alfa AWUS036AXML (MT7921AUN), and it appears to work
> well. Deauthentication during VIF operation (evil twin attack) is now
> working for MediaTek.
>
> Everything is documented at this comment in the GitHub thread
> (https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4167080451),
> including the patch used. A patch that is modifying these three files
> (tx.c, chan.c and ieee80211_i.h). Take a look at it  on the Github
> thread please.
>
> Regards.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 ||
> https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
>
> El dom, 29 mar 2026 a las 23:55, Óscar Alfonso Díaz
> (<oscar.alfonso.diaz@gmail.com>) escribió:
> >
> > Please review my latest messages in the GitHub thread.
> > https://github.com/morrownr/USB-WiFi/issues/682
> >
> > There you’ll even find a link to a video I recorded so you can see
> > that even on bare metal with Kali Linux installed natively, it still
> > doesn’t work. It behaves exactly the same as it does in the VM.
> >
> > Here is the link
> > https://www.dropbox.com/scl/fi/i6h8xbls5xkvae0pitrbg/video_2026-03-29_23-44-36.mp4?rlkey=jm48ly9tjwbhsi4aauml2auh9&dl=1
> >
> > Regards.
> > --
> > Oscar
> >
> > OpenPGP Key: DA9C60E9 ||
> > https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> > 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> > --
> >
> > El jue, 26 mar 2026 a las 13:16, Óscar Alfonso Díaz
> > (<oscar.alfonso.diaz@gmail.com>) escribió:
> > >
> > > Hi, in response to the three points:
> > >
> > > 1. VMware
> > >
> > > 2. This is the output of the lsusb command: "Bus 004 Device 002: ID
> > > 0e8d:7961 MediaTek Inc. Wireless_Device". The adapter is very cheap,
> > > it’s a Fenvi AX1800 (MT7921U), this one:
> > > https://s.click.aliexpress.com/e/_okxhxNl . But as I said, the bug
> > > also happens when using the Alfa AWUS036AXML (MT7921AUN).
> > >
> > > 3. I’m not sure about this right now. I’d say everything dies. I’ll
> > > test that to see if SSH is still available (I don’t think so, but I’m
> > > not 100% sure at the moment).
> > >
> > > Give me a few days. I’ll test this again over the weekend. I’ll also
> > > run a test on bare metal (not in a VM). That said, like me, many
> > > people use VMs for pentesting. So even if it works on bare metal,
> > > which I’ll test this weekend, I think it would still be worth
> > > investigating whether it can be fixed for VMs, since many people,
> > > myself included, use them for work. If it works with other WiFi
> > > adapters, it would be a big drawback if it didn’t work with MediaTek
> > > adapters.
> > >
> > > I’ll also reply with a similar message in the thread.
> > >
> > > Thanks and regards.
> > > --
> > > Oscar
> > >
> > > OpenPGP Key: DA9C60E9 ||
> > > https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> > > 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> > > --
> > >
> > > El jue, 26 mar 2026 a las 2:37, 傅继晗 (<fjhhz1997@gmail.com>) escribió:
> > > >
> > > > Hi Óscar,
> > > >
> > > > Lucid-Duck spent some time trying to reproduce your crash and wasn't able
> > > > to trigger it. Here's a summary of what was tested:
> > > >
> > > > - Kali 2025.4 (kernel 6.18.12+kali-amd64) VM on QEMU/KVM, with my v2
> > > >   patch applied
> > > > - MT7921AU USB adapter, passthrough to VM
> > > > - Full airgeddon evil twin flow: monitor VIF + hostapd AP + continuous
> > > >   deauth via aireplay-ng
> > > > - Also tested on bare metal Fedora 6.19.8 with the same adapter
> > > >
> > > > All tests were stable -- no crash, no dmesg errors, load stayed low. The
> > > > deauth frames were confirmed sending for 30+ seconds under the v2 patch
> > > > without issues.
> > > >
> > > > The one variable that couldn't be matched was the VM hypervisor.
> > > > Lucid-Duck used QEMU/KVM, which handles USB passthrough at the kernel
> > > > level (xHCI). If you're using VirtualBox or VMware, the USB passthrough
> > > > path is quite different (userspace proxy), and that could potentially
> > > > explain a total VM freeze that isn't a kernel panic.
> > > >
> > > > Could you please reply to Lucid-Duck directly on GitHub with the
> > > > following information? Here's the link:
> > > > https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4129198757
> > > >
> > > > 1. Which hypervisor are you using? (VirtualBox, VMware, QEMU/KVM, etc.)
> > > > 2. Your exact USB adapter model and ID? (0e8d:7961 covers several
> > > >    MT7921 variants)
> > > > 3. If possible, try SSHing into the VM from the host while the display
> > > >    is frozen -- if SSH still works, the issue is at the hypervisor/display
> > > >    level, not the kernel.
> > > >
> > > > Thanks,
> > > > 傅继晗

[PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Brite]

Monitor-mode packet injection is broken on drivers that implement
real channel context ops (mt76 and others) when the
monitor interface runs alongside another interface (typically AP).
The monitor VIF never gets a chanctx of its own in this case, so
ieee80211_monitor_start_xmit() finds vif.bss_conf.chanctx_conf ==
NULL and takes the fail_rcu path, silently dropping the skb. In
practice this breaks tooling like mdk4 and aireplay-ng on mt76
hardware, including airgeddon's evil-twin deauth flow, which runs
hostapd on an AP VIF and injects deauth frames from a coexisting
monitor VIF.

Earlier attempts on this thread addressed the same bug but had side
effects - notably full VM freezes during the airgeddon evil-twin flow,
reported by Óscar in the thread. This patch takes a different approach
and has not exhibited those side effects across the tested configurations.

Fix in two independent pieces:

1) Snapshot-based fallback. Maintain an RCU-published snapshot,
   local->sole_chandef, of the single active cfg80211_chan_def
   when exactly one non-transitional chanctx exists on the device,
   and NULL otherwise (MCC, mid-swap, idle, allocation failure).
   The snapshot is refreshed from four chanctx call sites
   (new/free/assign/change) under wiphy->mtx, and consumed
   lock-free by ieee80211_monitor_start_xmit() under rcu_read_lock().
   The wrapper struct carries an rcu_head so stale snapshots retire
   via kfree_rcu(). Fail-closed on ambiguous channel state rather
   than injecting on a guess.

   This restores AP+monitor coexistence injection on 2.4 GHz.

2) Surrogate sdata for the regulatory check on 5 GHz. Once the
   snapshot supplies a chandef, sdata is still the monitor
   interface (injection tools usually spoof the source MAC so the
   earlier addr2 match does not reassign sdata). On 5 GHz channels
   cfg80211_reg_can_beacon() then rejects the frame because
   NL80211_IFTYPE_MONITOR cannot satisfy the regulatory requirements
   for that band. In the coexistence scenario there is already a
   non-monitor VIF on the same channel that is authorised to operate
   there; locate a running non-monitor sdata with a matching chandef
   (cfg80211_chandef_identical: band, width, both center freqs) and
   use it for the regulatory check. An AP sdata satisfies the check,
   so the frame goes out on the correct channel instead of being
   dropped. If no such sdata exists the monitor interface is left in
   place and the existing code paths apply.

Tested on mt7921u (mt76) usb with mdk4 and aireplay-ng deauth on
2.4 GHz and 5 GHz while co-running an AP on the same channel.
Tested on 6.18.12, 6.19.12 and 7.0.0-rc5

Cc: stable@vger.kernel.org
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Reported-by: Óscar Alfonso Díaz <oscar.alfonso.diaz@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218763
Link: https://github.com/morrownr/USB-WiFi/issues/682
Signed-off-by: Brite <brite.airgeddon@gmail.com>
---
 net/mac80211/chan.c        | 75 ++++++++++++++++++++++++++++++++++++++
 net/mac80211/ieee80211_i.h | 17 +++++++++
 net/mac80211/main.c        |  7 ++++
 net/mac80211/tx.c          | 69 +++++++++++++++++++++++++++++++++--
 4 files changed, 165 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 05f45e66999b..9efab86f57d0 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -12,6 +12,61 @@
 #include "driver-ops.h"
 #include "rate.h"
 
+/**
+ * ieee80211_update_sole_chandef - refresh the sole-chanctx snapshot
+ * @local: the mac80211 device
+ *
+ * Walk chanctx_list.  If exactly one non-transitional, valid chanctx
+ * is present, kmalloc a snapshot of its chandef and RCU-publish it on
+ * local->sole_chandef.  If zero or more than one chanctx are active,
+ * publish NULL (fail-closed; injection disabled for MCC or idle).
+ *
+ * The prior snapshot is freed via kfree_rcu after all RCU readers that
+ * hold a reference to it complete.
+ *
+ * Context: Must be called with wiphy->mtx held.
+ *          Always process context - GFP_KERNEL is safe and appropriate.
+ */
+void ieee80211_update_sole_chandef(struct ieee80211_local *local)
+{
+	struct ieee80211_chanctx      *ctx, *found = NULL;
+	struct ieee80211_sole_chandef *snap = NULL;
+	struct ieee80211_sole_chandef *old;
+
+	lockdep_assert_wiphy(local->hw.wiphy);
+
+	list_for_each_entry(ctx, &local->chanctx_list, list) {
+		/*
+		 * REPLACES_OTHER: this entry is the incoming side of a
+		 * swap; the outgoing context is still live.  Skip it to
+		 * avoid counting a context that is not yet active.
+		 */
+		if (ctx->replace_state == IEEE80211_CHANCTX_REPLACES_OTHER)
+			continue;
+		if (!cfg80211_chandef_valid(&ctx->conf.def))
+			continue;
+
+		if (found) {
+			/* MCC or unexpected multi-channel state. */
+			found = NULL;
+			break;
+		}
+		found = ctx;
+	}
+
+	if (found) {
+		snap = kmalloc(sizeof(*snap), GFP_KERNEL);
+		if (snap)
+			snap->def = found->conf.def;
+		/* alloc failure -> snap == NULL -> publish NULL below */
+	}
+
+	old = rcu_replace_pointer(local->sole_chandef, snap,
+				  lockdep_is_held(&local->hw.wiphy->mtx));
+	if (old)
+		kfree_rcu(old, rcu_head);
+}
+
 struct ieee80211_chanctx_user_iter {
 	struct ieee80211_chan_req *chanreq;
 	struct ieee80211_sub_if_data *sdata;
@@ -729,6 +784,9 @@ static void ieee80211_change_chanctx(struct ieee80211_local *local,
 				     const struct ieee80211_chan_req *chanreq)
 {
 	_ieee80211_change_chanctx(local, ctx, old_ctx, chanreq, NULL);
+
+	/* Hook 4/4: channel parameters changed; refresh snapshot */
+	ieee80211_update_sole_chandef(local);
 }
 
 /* Note: if successful, the returned chanctx is reserved for the link */
@@ -902,6 +960,13 @@ ieee80211_new_chanctx(struct ieee80211_local *local,
 	WARN_ON_ONCE(err && !local->in_reconfig);
 
 	list_add_rcu(&ctx->list, &local->chanctx_list);
+	/*
+	 * Hook 1/4: new context is now on the list.
+	 * Publish a fresh snapshot so monitor injection can use this
+	 * channel immediately.
+	 */
+	ieee80211_update_sole_chandef(local);
+
 	return ctx;
 }
 
@@ -928,6 +993,13 @@ static void ieee80211_free_chanctx(struct ieee80211_local *local,
 	WARN_ON_ONCE(ieee80211_chanctx_refcount(local, ctx) != 0);
 
 	list_del_rcu(&ctx->list);
+	/*
+	 * Hook 2/4: context is now off the list.
+	 * Republish so that a context removed during AP teardown is no
+	 * longer visible to the monitor injection fallback.
+	 */
+	ieee80211_update_sole_chandef(local);
+
 	ieee80211_del_chanctx(local, ctx, skip_idle_recalc);
 	kfree_rcu(ctx, rcu_head);
 }
@@ -1061,6 +1133,9 @@ static int ieee80211_assign_link_chanctx(struct ieee80211_link_data *link,
 		ieee80211_recalc_chanctx_min_def(local, new_ctx);
 	}
 
+	/* Hook 3/4: VIF assigned or unassigned; refresh snapshot */
+	ieee80211_update_sole_chandef(local);
+
 	if (conf) {
 		new_idle = false;
 	} else {
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index e60b814dd89e..14c412a18868 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -40,6 +40,22 @@ extern const struct cfg80211_ops mac80211_config_ops;
 
 struct ieee80211_local;
 struct ieee80211_mesh_fast_tx;
+/**
+ * struct ieee80211_sole_chandef - kfree_rcu-capable chandef snapshot
+ *
+ * cfg80211_chan_def has no embedded rcu_head so it cannot be freed
+ * with kfree_rcu() directly.  This wrapper adds one.
+ *
+ * @rcu_head: for kfree_rcu() deferred freeing
+ * @def:      point-in-time copy of the active cfg80211_chan_def
+ */
+struct ieee80211_sole_chandef {
+	struct rcu_head          rcu_head;
+	struct cfg80211_chan_def def;
+};
+
+/* Defined in chan.c */
+void ieee80211_update_sole_chandef(struct ieee80211_local *local);
 
 /* Maximum number of broadcast/multicast frames to buffer when some of the
  * associated stations are using power saving. */
@@ -1586,6 +1602,7 @@ struct ieee80211_local {
 
 	/* channel contexts */
 	struct list_head chanctx_list;
+	struct ieee80211_sole_chandef __rcu *sole_chandef;
 
 #ifdef CONFIG_MAC80211_LEDS
 	struct led_trigger tx_led, rx_led, assoc_led, radio_led;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 616f86b1a7e4..387ed2786b32 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1745,6 +1745,13 @@ void ieee80211_free_hw(struct ieee80211_hw *hw)
 		kfree(local->hw.wiphy->bands[band]);
 	}
 
+	/*
+	 * All interfaces are gone by this point, so every chanctx has been
+	 * freed and ieee80211_update_sole_chandef() has already published
+	 * NULL. Assert the invariant.
+	 */
+	WARN_ON_ONCE(rcu_access_pointer(local->sole_chandef));
+
 	wiphy_free(local->hw.wiphy);
 }
 EXPORT_SYMBOL(ieee80211_free_hw);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index b90c0537d0c5..54d06cfb670c 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2398,10 +2398,73 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 				rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
 	}
 
-	if (chanctx_conf)
+	if (chanctx_conf) {
 		chandef = &chanctx_conf->def;
-	else
-		goto fail_rcu;
+	} else {
+		/*
+		 * Real-chanctx drivers (e.g. mt76) do not assign a chanctx to
+		 * the monitor VIF, so vif.bss_conf.chanctx_conf is NULL here.
+		 * Fall back to the sole_chandef snapshot maintained by
+		 * ieee80211_update_sole_chandef(). NULL means MCC or no active
+		 * channel - drop the frame.
+		 *
+		 * The snapshot is valid for this whole function: it is freed
+		 * via kfree_rcu() after a full grace period, and we are inside
+		 * rcu_read_lock() throughout.
+		 */
+		struct ieee80211_sole_chandef *sole =
+			rcu_dereference(local->sole_chandef);
+		chandef = sole ? &sole->def : NULL;
+		if (!chandef)
+			goto fail_rcu;
+	}
+
+	/*
+	 * If sdata is still the monitor interface, addr2 did not match any
+	 * local non-monitor interface - the normal case for injection tools
+	 * (mdk4, aireplay-ng) that spoof the source MAC.
+	 *
+	 * On 5 GHz, cfg80211_reg_can_beacon() below commonly rejects
+	 * NL80211_IFTYPE_MONITOR because a monitor interface cannot
+	 * satisfy the regulatory requirements for the band (NO_IR on
+	 * many channels; radar-detection responsibility on DFS channels).
+	 * Pick a running non-monitor sdata operating on the same channel
+	 * (identical band, width and both center frequencies) and use
+	 * that for the check: an AP sdata is already authorised for the
+	 * channel, so the check passes and the frame goes out on the
+	 * correct channel instead of being dropped.
+	 *
+	 * If no such sdata exists, leave sdata as the monitor interface and
+	 * let the existing code paths handle the MONITOR case (CHAN_CAN_MONITOR
+	 * branch, or fail_rcu if regulatory does not permit).
+	 */
+	if (sdata->vif.type == NL80211_IFTYPE_MONITOR) {
+		struct ieee80211_sub_if_data *picked = NULL;
+
+		list_for_each_entry_rcu(tmp_sdata, &local->interfaces, list) {
+			struct ieee80211_chanctx_conf *tx_conf;
+
+			if (!ieee80211_sdata_running(tmp_sdata))
+				continue;
+			if (tmp_sdata->vif.type == NL80211_IFTYPE_MONITOR ||
+			    tmp_sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+				continue;
+
+			tx_conf = rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
+
+			if (!tx_conf)
+				continue;
+
+			if (!cfg80211_chandef_identical(&tx_conf->def, chandef))
+				continue;
+
+			picked = tmp_sdata;
+			break;
+		}
+
+		if (picked)
+			sdata = picked;
+	}
 
 	/*
 	 * If driver/HW supports IEEE80211_CHAN_CAN_MONITOR we still
-- 
2.53.0

Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Greg KH]

On Sat, Apr 25, 2026 at 12:08:07AM +1200, Brite wrote:
> Monitor-mode packet injection is broken on drivers that implement
> real channel context ops (mt76 and others) when the
> monitor interface runs alongside another interface (typically AP).
> The monitor VIF never gets a chanctx of its own in this case, so
> ieee80211_monitor_start_xmit() finds vif.bss_conf.chanctx_conf ==
> NULL and takes the fail_rcu path, silently dropping the skb. In
> practice this breaks tooling like mdk4 and aireplay-ng on mt76
> hardware, including airgeddon's evil-twin deauth flow, which runs
> hostapd on an AP VIF and injects deauth frames from a coexisting
> monitor VIF.

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file,
  Documentation/process/submitting-patches.rst for how to do this
  correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Johannes Berg]

On Sat, 2026-04-25 at 00:08 +1200, Brite wrote:
> 
> Earlier attempts on this thread addressed the same bug but had side
> effects - notably full VM freezes during the airgeddon evil-twin flow,
> reported by Óscar in the thread. This patch takes a different approach
> and has not exhibited those side effects across the tested configurations.
> 

I don't believe that all this complexity is necessary, and the code
changes have are fairly clearly LLM-created w/o such disclosures.
Dropping.

johannes

Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Óscar Alfonso Díaz]

Dropping? Do you mean it will not be taken into consideration?

I tested this patch thoroughly, and it works very well. I am well
aware that kernel developers are reluctant to accept anything created
by AI or LLMs, of course. But please, I think you should review the
approach and perhaps use the idea to implement it in the way you think
is most appropriate.

Brite has put a lot of effort and time into this, and both he and I
have spent a great deal of time testing everything. It has been tested
as he describes on kernel 7.0 and on the backported versions. Side
effects have been addressed, and everything is finally working well.

All we ask is that it be taken into consideration for adding a
solution upstream.

I already have a .deb package that works for me on the Linux
distribution I use, but it would be wonderful to provide a fix to the
whole community so it works for everyone. Please, I kindly ask that
you take some time to review it.

Thanks so much, as always. Kind regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El vie, 24 abr 2026 a las 15:55, Johannes Berg
(<johannes@sipsolutions.net>) escribió:
>
> On Sat, 2026-04-25 at 00:08 +1200, Brite wrote:
> >
> > Earlier attempts on this thread addressed the same bug but had side
> > effects - notably full VM freezes during the airgeddon evil-twin flow,
> > reported by Óscar in the thread. This patch takes a different approach
> > and has not exhibited those side effects across the tested configurations.
> >
>
> I don't believe that all this complexity is necessary, and the code
> changes have are fairly clearly LLM-created w/o such disclosures.
> Dropping.
>
> johannes

Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Brite]

On April 25, 2026 1:55:46 AM GMT+12:00, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>I don't believe that all this complexity is necessary, and the code
>changes have are fairly clearly LLM-created w/o such disclosures.
>Dropping.
>
Are you saying that the patch itself is created by llm? If yes, is that even possible? I do accept that yourself or experienced devs could come up with the simplest of a solution. My initial patch was spread across 6 or 7 files with a lot of debug lines added to find out the location of vm freeze. It has taken a lot of time to narrow it down to this patch. It's totally ok if you're dropping this but if you could at least see what this code does and do a proper minimal fix yourself, that would help out a lot of people in the community. 

The only time I used the help of ai and google was during the initial stage trying to understand the different variables, structures, pointers etc. After that it was just me adding a lot of debug lines to all suspected functions but the vm froze even before anything got printed in dmesg. Then i added delay between the debugs and was finally able to see where the freeze happened. This might be totally unnecessary for an experienced dev like you but since I'm new, I found this the easiest way to get to the root of the issue. 
I also took help from ai and google to help me prepare the patch file in the required format to be sent. 
I don't understand why you think the whole patch is generated by llm. I wonder if it was that easy to be done.

Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Brite]

On April 25, 2026 1:55:46 AM GMT+12:00, Johannes Berg <johannes@sipsolutions.net> wrote:
>I don't believe that all this complexity is necessary, and the code
>changes have are fairly clearly LLM-created w/o such disclosures.
>Dropping.
>
If it helps in any way - just tested your v2 patch which causes VM freeze but adding the 5ghz surrogate patch solves the freeze and also the issue with 5ghz deauth in ap/monitor mode coexistence. Tested working on 2.4/5ghz standalone and 2.4/5ghz ap/coexistence mode using ath9k_htc and mt7921u. Also tested side by side ap/deauth coexistence mode running evil twin attack using airgeddon multi instance mode including channel change monitor and no issues at all.

Brite

Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Lachlan Hodges]

Hi,

I will leave implementation discussion to Johannes, but I have some
generic feedback;

> + * Context: Must be called with wiphy->mtx held.
> + *          Always process context - GFP_KERNEL is safe and appropriate.

This comment seems redundant given the lockdep assert?

> + */
> +void ieee80211_update_sole_chandef(struct ieee80211_local *local)
> +{
> +	struct ieee80211_chanctx      *ctx, *found = NULL;
> +	struct ieee80211_sole_chandef *snap = NULL;
> +	struct ieee80211_sole_chandef *old;

Don't align the local names i.e

	struct ieee80211_chanctx *ctx, *found = NULL;
	struct ieee80211_sole_chandef *snap = NULL;
	...

> +	if (found) {
> +		snap = kmalloc(sizeof(*snap), GFP_KERNEL);
> +		if (snap)
> +			snap->def = found->conf.def;
> +		/* alloc failure -> snap == NULL -> publish NULL below */

Same here - this comment adds no value

>  struct ieee80211_chanctx_user_iter {
>  	struct ieee80211_chan_req *chanreq;
>  	struct ieee80211_sub_if_data *sdata;
> @@ -729,6 +784,9 @@ static void ieee80211_change_chanctx(struct ieee80211_local *local,
>  				     const struct ieee80211_chan_req *chanreq)
>  {
>  	_ieee80211_change_chanctx(local, ctx, old_ctx, chanreq, NULL);
> +
> +	/* Hook 4/4: channel parameters changed; refresh snapshot */
> +	ieee80211_update_sole_chandef(local);

Without the context of this patch, there is no way to understand
what this is doing (same with 3/4). The comment doesn't help and
the general idea of a "sole chandef" seems strange. hw.conf.chandef
is also a sole chandef?

> +/* Defined in chan.c */
> +void ieee80211_update_sole_chandef(struct ieee80211_local *local);

Another comment not needed
 
> +	/*
> +	 * All interfaces are gone by this point, so every chanctx has been
> +	 * freed and ieee80211_update_sole_chandef() has already published
> +	 * NULL. Assert the invariant.
> +	 */
> +	WARN_ON_ONCE(rcu_access_pointer(local->sole_chandef));

Seems unnecessary?
 
> -	if (chanctx_conf)
> +	if (chanctx_conf) {
>  		chandef = &chanctx_conf->def;
> -	else
> -		goto fail_rcu;
> +	} else {
> +		/*
> +		 * Real-chanctx drivers (e.g. mt76) do not assign a chanctx to
> +		 * the monitor VIF, so vif.bss_conf.chanctx_conf is NULL here.
> +		 * Fall back to the sole_chandef snapshot maintained by
> +		 * ieee80211_update_sole_chandef(). NULL means MCC or no active
> +		 * channel - drop the frame.
> +		 *
> +		 * The snapshot is valid for this whole function: it is freed
> +		 * via kfree_rcu() after a full grace period, and we are inside
> +		 * rcu_read_lock() throughout.
> +		 */

is the bottom half of this comment really needed?

> +		struct ieee80211_sole_chandef *sole =
> +			rcu_dereference(local->sole_chandef);
> +		chandef = sole ? &sole->def : NULL;

nit: space after local declaration

> +		list_for_each_entry_rcu(tmp_sdata, &local->interfaces, list) {
> +			struct ieee80211_chanctx_conf *tx_conf;
> +
> +			if (!ieee80211_sdata_running(tmp_sdata))
> +				continue;
> +			if (tmp_sdata->vif.type == NL80211_IFTYPE_MONITOR ||
> +			    tmp_sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
> +				continue;
> +
> +			tx_conf = rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
> +

nit: remove this space after tx_conf = ..

lachlan

Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Brite]

On April 25, 2026 1:47:28 PM GMT+12:00, Lachlan Hodges <lachlan.hodges@morsemicro.com> wrote:
>Hi,
>
>I will leave implementation discussion to Johannes, but I have some
>generic feedback;
>
Thanks for the feedback and now i know why the code was flagged as llm created. My approach to finding the vm freeze issue followed by the 5ghz deauth not working, was done using debug prints everywhere possible, with added delays between function calls(the delay was added because the vm froze otherwise, without any dmesg logs). Since I didn't have the proper knowledge, the fixes i tried initially (spread across 6 or 7 files) led to other issues, intermittent failures etc. Everything was done inside a kali VM with no comments, full of messy code, not using git commits to revert etc. i had to start from scratch but then i added comments alongside. Even though the initial patch fixed every issue, being too invasive, I tried to trim down as much as I could which landed the sole chandef and then the 5ghz patch. I didn't pay attention to improving the comments when removing code sections. I also had very limited time to spare for this and my intention as I said in the airgeddon discord channel was to send a cleaned up code to the kernel devs so that they could get a hint at what the issue is and come up with a proper fix. The commit message is what i summed up from doing all my research and testing. I didn't know the format to submit a patch, so i used information from AI, Google, previous threads/replies etc here to submit an email. I didn't check if AI changed any comments. 
As I mentioned earlier, a community had been waiting for so long to have this issue fixed. My sole intention was to find anything that helps with resolving this. I've also packaged 6.18, 6.19 and 7.0 with the patch and uploaded it for the users now but as Oscar said the proper way would be a fix in the upstream and backporting it.
If v2 patch by Johannes(no need for sole_chandef) + 5ghz patch from me fixes the whole issue(I've tested this today) please look into improving it and providing a fix.
Thanks

Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF

[Óscar Alfonso Díaz]

Hello. I've tested as well the johannes v2 patch + the 5ghz fix and it
works very well. I've tested normal DoS, 5ghz DoS and VIF+DoS using a
MediaTek chipset and also a Ralink chipset. Everything worked like a
charm.

I must say this patch is pretty simple... just modifying one file
(tx.c) and it is a minimum change (not done by LLM). I think this is
the best approach. What do you think Johannes?

Regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El sáb, 25 abr 2026 a las 4:43, Brite (<brite.airgeddon@gmail.com>) escribió:
>
>
>
> On April 25, 2026 1:47:28 PM GMT+12:00, Lachlan Hodges <lachlan.hodges@morsemicro.com> wrote:
> >Hi,
> >
> >I will leave implementation discussion to Johannes, but I have some
> >generic feedback;
> >
> Thanks for the feedback and now i know why the code was flagged as llm created. My approach to finding the vm freeze issue followed by the 5ghz deauth not working, was done using debug prints everywhere possible, with added delays between function calls(the delay was added because the vm froze otherwise, without any dmesg logs). Since I didn't have the proper knowledge, the fixes i tried initially (spread across 6 or 7 files) led to other issues, intermittent failures etc. Everything was done inside a kali VM with no comments, full of messy code, not using git commits to revert etc. i had to start from scratch but then i added comments alongside. Even though the initial patch fixed every issue, being too invasive, I tried to trim down as much as I could which landed the sole chandef and then the 5ghz patch. I didn't pay attention to improving the comments when removing code sections. I also had very limited time to spare for this and my intention as I said in the airgeddon discord channel was to send a cleaned up code to the kernel devs so that they could get a hint at what the issue is and come up with a proper fix. The commit message is what i summed up from doing all my research and testing. I didn't know the format to submit a patch, so i used information from AI, Google, previous threads/replies etc here to submit an email. I didn't check if AI changed any comments.
> As I mentioned earlier, a community had been waiting for so long to have this issue fixed. My sole intention was to find anything that helps with resolving this. I've also packaged 6.18, 6.19 and 7.0 with the patch and uploaded it for the users now but as Oscar said the proper way would be a fix in the upstream and backporting it.
> If v2 patch by Johannes(no need for sole_chandef) + 5ghz patch from me fixes the whole issue(I've tested this today) please look into improving it and providing a fix.
> Thanks

[PATCH v2 0/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

This is v2 of fjh1997's patch, carried over at his request after his
reply on morrownr/USB-WiFi#682. Compared to v1: the substantive
change is the list_is_singular() guard agreed on in the v1 review
thread, so the fallback only fires when the chanctx_list is
unambiguous. The surrounding else block is also collapsed into a
single else-if matching the shape d594cc6f2c58 used for the emulate
case, and the v1 local ctx variable plus inline comment are dropped
(the rationale lives here in the commit message instead).

On the hang reports against the previous attempts at this fix (Oscar
against v1 in his March 19 2026 lore reply, and Johannes's Dec 2025
v2 at 20251216111909.25076-2-johannes@sipsolutions.net, held back for
similar reasons), I reran the airgeddon evil-twin flow (hostapd AP +
monitor VIF on the same phy + aireplay-ng deauth from the monitor) on
three setups:

GMKtec NucBox K8 Plus (MT7922 PCIe, in-kernel mt7921e, kernel 7.0.5):
  Stock and patched: no hang on 2.4 GHz or 5 GHz. dmesg clean.

Pi 5 (Alfa AWUS036AXML USB, OOT mt76 carrying morrownr/mt76 commit
903b05918523 "mt7921: assert sniffer enable on chanctx change",
kernel 6.12.47):
  Patched: no hang on 2.4 GHz or 5 GHz. dmesg clean.

Kali Linux 2026.1 VM, kernel 6.19.14+kali-amd64 (matching Oscar's
reported environment: Kali, MT7921U via USB passthrough of the Alfa
AWUS036AXML to a KVM guest; airgeddon 11.61 installed; v2 mac80211
built in-VM, installed, and loaded as the OOT-tainted module):
  Patched: no hang on 2.4 GHz or 5 GHz. dmesg clean (0 errors,
  0-1 warnings). Slab delta under 2 MB per 30 s run.

Patched did not hang on any of the three setups; K8 Plus stock also
cleared the same flow on both bands (Pi 5 and the Kali VM were
tested patched only). The prior reports look environment-specific to
Oscar's rig rather than kernel-side. If Oscar sees a recurrence on
this v2 I will iterate with him on the thread.

Discussion: https://github.com/morrownr/USB-WiFi/issues/682

傅继晗 (1):
  wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

 net/mac80211/tx.c | 4 ++++
 1 file changed, 4 insertions(+)

--
2.43.0

[PATCH v2 1/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

From: 傅继晗 <fjhhz1997@gmail.com>

Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
behaviour") restored the monitor injection fallback for drivers using
chanctx emulation but explicitly deferred the harder case of drivers
that transitioned to real chanctx ops. mt76 falls in that category
and still drops every injected frame when monitor coexists with
another interface.

When the monitor has no chanctx of its own and exactly one chanctx is
in flight, fall back to that one. Otherwise refuse: picking
arbitrarily across multiple chanctxs would inject onto an unrelated
channel.

Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
VIF on the same phy + aireplay-ng deauth from the monitor) against
this patch on mt7921e PCIe and mt7921u USB, across both 2.4 GHz and
5 GHz, and again on a Kali Linux VM with MT7921U USB-passthrough as
the closest match to the original reporter's setup. None of those
reproduced the hang reported against the earlier attempt at the same
fix (<20251216111909.25076-2-johannes@sipsolutions.net>) or against
v1 on lore in March 2026.

Cc: stable@vger.kernel.org # 6.9+
Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Link: https://github.com/morrownr/USB-WiFi/issues/682
Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
 net/mac80211/tx.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2402,6 +2402,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 		chandef = &chanctx_conf->def;
 	else if (local->emulate_chanctx)
 		chandef = &local->hw.conf.chandef;
+	else if (list_is_singular(&local->chanctx_list))
+		chandef = &list_first_entry(&local->chanctx_list,
+					    struct ieee80211_chanctx,
+					    list)->conf.def;
 	else
 		goto fail_rcu;
 
-- 
2.54.0

Re: [PATCH v2 1/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

On Sun, 2026-05-17 at 23:40 -0700, Devin Wittmayer wrote:
> From: 傅继晗 <fjhhz1997@gmail.com>
> 
> Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
> behaviour") restored the monitor injection fallback for drivers using
> chanctx emulation but explicitly deferred the harder case of drivers
> that transitioned to real chanctx ops. mt76 falls in that category
> and still drops every injected frame when monitor coexists with
> another interface.
> 
> When the monitor has no chanctx of its own and exactly one chanctx is
> in flight, fall back to that one. Otherwise refuse: picking
> arbitrarily across multiple chanctxs would inject onto an unrelated
> channel.
> 
> Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
> VIF on the same phy + aireplay-ng deauth from the monitor) against
> this patch on mt7921e PCIe and mt7921u USB, across both 2.4 GHz and
> 5 GHz, and again on a Kali Linux VM with MT7921U USB-passthrough as
> the closest match to the original reporter's setup. None of those
> reproduced the hang reported against the earlier attempt at the same
> fix (<20251216111909.25076-2-johannes@sipsolutions.net>) or against
> v1 on lore in March 2026.
> 
> Cc: stable@vger.kernel.org # 6.9+
> Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
> Link: https://github.com/morrownr/USB-WiFi/issues/682
> Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> ---
>  net/mac80211/tx.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -2402,6 +2402,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
>  		chandef = &chanctx_conf->def;
>  	else if (local->emulate_chanctx)
>  		chandef = &local->hw.conf.chandef;
> +	else if (list_is_singular(&local->chanctx_list))
> +		chandef = &list_first_entry(&local->chanctx_list,
> +					    struct ieee80211_chanctx,
> +					    list)->conf.def;


Quoting include/linux/rculist.h:

 * Where are list_empty_rcu() and list_first_entry_rcu()?
 *
 * They do not exist because they would lead to subtle race conditions:
 *
 * if (!list_empty_rcu(mylist)) {
 *      struct foo *bar = list_first_entry_rcu(mylist, struct foo, list_member);
 *      do_something(bar);
 * }
 *
 * The list might be non-empty when list_empty_rcu() checks it, but it
 * might have become empty by the time that list_first_entry_rcu() rereads
 * the ->next pointer, which would result in a SEGV.
 *
 * When not using RCU, it is OK for list_first_entry() to re-read that
 * pointer because both functions should be protected by some lock that
 * blocks writers.
 *
 * When using RCU, list_empty() uses READ_ONCE() to fetch the
 * RCU-protected ->next pointer and then compares it to the address of the
 * list head.  However, it neither dereferences this pointer nor provides
 * this pointer to its caller.  Thus, READ_ONCE() suffices (that is,
 * rcu_dereference() is not needed), which means that list_empty() can be
 * used anywhere you would want to use list_empty_rcu().  Just don't
 * expect anything useful to happen if you do a subsequent lockless
 * call to list_first_entry_rcu()!!!
 *
 * See list_first_or_null_rcu for an alternative.

johannes

[PATCH v3 0/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

v2 [1] used list_is_singular() + list_first_entry() to find the
fallback chanctx. Johannes pointed out [2] that the pair is the
rculist.h anti-pattern: the two reads of head->next race
list_del_rcu() of the sole entry between the singularity check
and the entry fetch. v3 uses list_first_or_null_rcu() with an
rcu_access_pointer() check that the entry is the only one in
the list, as rculist.h suggests.

The v2 user-visible TX path is unchanged in v3, so my Tested-by
from v2 carries forward: the airgeddon evil-twin flow on mt7921e
PCIe + mt7921u USB + Kali VM with MT7921U passthrough still
applies.

[1] https://lore.kernel.org/linux-wireless/20260518064025.96792-1-lucid_duck@justthetip.ca/
[2] https://lore.kernel.org/linux-wireless/70c49e598ffba2864c8168c7185c0abec76b59dd.camel@sipsolutions.net/

傅继晗 (1):
  wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

 net/mac80211/tx.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

[PATCH v3] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

From: 傅继晗 <fjhhz1997@gmail.com>

Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
behaviour") restored the monitor injection fallback for drivers using
chanctx emulation but explicitly deferred the harder case of drivers
that transitioned to real chanctx ops. mt76 falls in that category
and still drops every injected frame when monitor coexists with
another interface.

When the monitor has no chanctx of its own, fall back to the only
chanctx in flight if there is exactly one. Refuse if multiple are
present: picking arbitrarily would inject onto an unrelated channel.

Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
VIF on the same phy + aireplay-ng deauth from the monitor) on
mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a
Kali VM with MT7921U passthrough as the closest match to the
original reporter's setup. None reproduced the hang seen against
the earlier attempt at this fix
(<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1
on lore in March.

Cc: stable@vger.kernel.org # 6.9+
Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
Closes: https://github.com/morrownr/USB-WiFi/issues/682
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
v3:
  - Replace list_is_singular() + list_first_entry() with
    list_first_or_null_rcu() and an rcu_access_pointer() check
    that the entry is the only one in the list. The v2 pair
    re-read ->next without RCU between the singularity check
    and the entry fetch, racing list_del_rcu() of the sole entry
    (rculist.h).
  - Tested-by carries from v2: v3 changes the lookup primitive
    only, not the TX path, so the v2 airgeddon evil-twin flow on
    mt7921e/mt7921u/Kali-VM still applies.

v2:
  - First respin under my submitter signoff; preserves fjh1997
    authorship.
  - Verification matrix; airgeddon evil-twin flow on mt7921e/
    mt7921u/Kali-VM does not reproduce the hang reported against
    the v1 attempt at this fix.

 net/mac80211/tx.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 933c86ca21c3..6d2c71a13f26 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2407,12 +2407,20 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 				rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
 	}
 
-	if (chanctx_conf)
+	if (chanctx_conf) {
 		chandef = &chanctx_conf->def;
-	else if (local->emulate_chanctx)
+	} else if (local->emulate_chanctx) {
 		chandef = &local->hw.conf.chandef;
-	else
-		goto fail_rcu;
+	} else {
+		struct ieee80211_chanctx *ctx;
+
+		ctx = list_first_or_null_rcu(&local->chanctx_list,
+					     struct ieee80211_chanctx, list);
+		if (!ctx ||
+		    rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
+			goto fail_rcu;
+		chandef = &ctx->conf.def;
+	}
 
 	/*
 	 * If driver/HW supports IEEE80211_CHAN_CAN_MONITOR we still

Re: [PATCH v3] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

Hi Devin,

Please don't nest the threads - it gets confusing quickly.


> +	} else if (local->emulate_chanctx) {
>  		chandef = &local->hw.conf.chandef;
> -	else
> -		goto fail_rcu;
> +	} else {
> +		struct ieee80211_chanctx *ctx;
> +
> +		ctx = list_first_or_null_rcu(&local->chanctx_list,
> +					     struct ieee80211_chanctx, list);
> +		if (!ctx ||
> +		    rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
> +			goto fail_rcu;
> +		chandef = &ctx->conf.def;
> +	}

I'm sure we can basically get rid of the "emulate" check now, because
emulation will always lead to exactly (zero or) one channel context(s)
being present.

And then it's equivalent to my original v2 patch:
https://lore.kernel.org/linux-wireless/20251216111909.25076-2-johannes@sipsolutions.net/

(even if that expressed the logic somewhat differently)


And that version was _definitely_ reported to crash. So what changed?
Could you do some investigation if mt76 got bugfixes in this area
perhaps? Or are you just using slightly different devices than Oscar?

johannes

Re: [PATCH v3] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

Hi Johannes,

Apologies for the nesting -- I'll keep replies top-level from here.

On 19 May 2026 00:02 (CEST), Johannes Berg wrote:
> I'm sure we can basically get rid of the "emulate" check now

Agreed. v4 will drop it.

> So what changed? Could you do some investigation if mt76 got bugfixes
> in this area perhaps? Or are you just using slightly different devices
> than Oscar?

Same chip family. Oscar's MT7921U/MT7921AUN (0e8d:7961) matches my v3
rigs (mt7921e PCIe, mt7921u USB, Kali VM with MT7921U passthrough).

mt76 has had three chanctx-touching commits since 2025-12-16 (de62b24224ac
"abort ROC on chanctx changes", f0fb9afb74ec "check chanctx before
restoring channel after ROC", 381733b3a14a "nullfunc PS on offchannel
transitions"). None touches ieee80211_monitor_start_xmit or the
chanctx_list lookup v3 does.

I think it's the reproducer environment. Back in March I matched Oscar's
stack -- Kali 6.18.12, fjh1997 v2 applied, MT7921U passthrough, airgeddon
evil twin, aireplay-ng deauth into the monitor VIF. No crash. The one
variable I couldn't match was the hypervisor: I used QEMU/KVM, Oscar
hasn't said. The symptoms (instant VM freeze on deauth start) read more
like a hypervisor USB-proxy stall than a kernel hang.

I'll send v4 with the collapse.

Devin

[PATCH v4 0/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

v3 [1] kept the existing local->emulate_chanctx branch alongside the
new single-chanctx fallback. Johannes pointed out [2] that emulation
always presents zero or one chanctxs in local->chanctx_list, so the
new fallback handles that path as well. v4 drops the branch.

The real-chanctx TX path is unchanged from v3, so my v3 Tested-by
carries: the airgeddon evil-twin flow on mt7921e PCIe + mt7921u USB
+ Kali VM with MT7921U passthrough still applies.

[1] https://lore.kernel.org/linux-wireless/20260518170147.13885-1-lucid_duck@justthetip.ca/
[2] https://lore.kernel.org/linux-wireless/58d6ee4054473af391eb5ae8b4382e6964dc3ab6.camel@sipsolutions.net/

傅继晗 (1):
  wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

 net/mac80211/tx.c | 16 ++++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

[PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

From: 傅继晗 <fjhhz1997@gmail.com>

Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
behaviour") restored the monitor injection fallback for drivers using
chanctx emulation but explicitly deferred drivers that transitioned
to real chanctx ops. mt76 falls in that category and still drops
every injected frame when monitor coexists with another interface.

When the monitor has no chanctx of its own, fall back to the only
chanctx in flight if there is exactly one. Refuse if multiple are
present: picking arbitrarily would inject on an unrelated channel.
Emulated and real chanctx drivers both flow through this fallback,
since emulation always presents zero or one chanctx in
local->chanctx_list.

Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
VIF on the same phy + aireplay-ng deauth from the monitor) on
mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a
Kali VM with MT7921U passthrough as the closest match to the
original reporter's setup. None reproduced the hang seen against
the earlier attempt at this fix
(<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1
on lore in March.

Cc: stable@vger.kernel.org # 6.9+
Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
Closes: https://github.com/morrownr/USB-WiFi/issues/682
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
v4:
  - Drop the dedicated local->emulate_chanctx branch. Emulation always
    presents zero or one chanctx in local->chanctx_list, so the
    single-chanctx walk handles that path too.
  - Real-chanctx TX path is unchanged, so v3 Tested-by carries.

v3:
  - Replace list_is_singular() + list_first_entry() with
    list_first_or_null_rcu() and an rcu_access_pointer() check
    that the entry is the only one in the list. The v2 pair
    re-read ->next without RCU between the singularity check
    and the entry fetch, racing list_del_rcu() of the sole entry
    (rculist.h).

v2:
  - First respin under my submitter signoff; preserves fjh1997
    authorship.
  - Verification matrix; airgeddon evil-twin flow on mt7921e/
    mt7921u/Kali-VM does not reproduce the hang reported against
    the v1 attempt at this fix.

 net/mac80211/tx.c | 16 ++++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 933c86ca21c3..a8c5d3a2b1f0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2407,12 +2407,18 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 				rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
 	}
 
-	if (chanctx_conf)
+	if (chanctx_conf) {
 		chandef = &chanctx_conf->def;
-	else if (local->emulate_chanctx)
-		chandef = &local->hw.conf.chandef;
-	else
-		goto fail_rcu;
+	} else {
+		struct ieee80211_chanctx *ctx;
+
+		ctx = list_first_or_null_rcu(&local->chanctx_list,
+					     struct ieee80211_chanctx, list);
+		if (!ctx ||
+		    rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
+			goto fail_rcu;
+		chandef = &ctx->conf.def;
+	}
 
 	/*
 	 * If driver/HW supports IEEE80211_CHAN_CAN_MONITOR we still
-- 
2.54.0

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Óscar Alfonso Díaz]

Let me know if any testing of a concrete patch is needed when you feel
it is completely fixed.

P.S. My environment was Kali VM using Vmware.

Regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El mié, 20 may 2026 a las 1:57, Devin Wittmayer
(<lucid_duck@justthetip.ca>) escribió:
>
> From: 傅继晗 <fjhhz1997@gmail.com>
>
> Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
> behaviour") restored the monitor injection fallback for drivers using
> chanctx emulation but explicitly deferred drivers that transitioned
> to real chanctx ops. mt76 falls in that category and still drops
> every injected frame when monitor coexists with another interface.
>
> When the monitor has no chanctx of its own, fall back to the only
> chanctx in flight if there is exactly one. Refuse if multiple are
> present: picking arbitrarily would inject on an unrelated channel.
> Emulated and real chanctx drivers both flow through this fallback,
> since emulation always presents zero or one chanctx in
> local->chanctx_list.
>
> Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
> VIF on the same phy + aireplay-ng deauth from the monitor) on
> mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a
> Kali VM with MT7921U passthrough as the closest match to the
> original reporter's setup. None reproduced the hang seen against
> the earlier attempt at this fix
> (<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1
> on lore in March.
>
> Cc: stable@vger.kernel.org # 6.9+
> Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
> Closes: https://github.com/morrownr/USB-WiFi/issues/682
> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
> Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> ---
> v4:
>   - Drop the dedicated local->emulate_chanctx branch. Emulation always
>     presents zero or one chanctx in local->chanctx_list, so the
>     single-chanctx walk handles that path too.
>   - Real-chanctx TX path is unchanged, so v3 Tested-by carries.
>
> v3:
>   - Replace list_is_singular() + list_first_entry() with
>     list_first_or_null_rcu() and an rcu_access_pointer() check
>     that the entry is the only one in the list. The v2 pair
>     re-read ->next without RCU between the singularity check
>     and the entry fetch, racing list_del_rcu() of the sole entry
>     (rculist.h).
>
> v2:
>   - First respin under my submitter signoff; preserves fjh1997
>     authorship.
>   - Verification matrix; airgeddon evil-twin flow on mt7921e/
>     mt7921u/Kali-VM does not reproduce the hang reported against
>     the v1 attempt at this fix.
>
>  net/mac80211/tx.c | 16 ++++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 933c86ca21c3..a8c5d3a2b1f0 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -2407,12 +2407,18 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
>                                 rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
>         }
>
> -       if (chanctx_conf)
> +       if (chanctx_conf) {
>                 chandef = &chanctx_conf->def;
> -       else if (local->emulate_chanctx)
> -               chandef = &local->hw.conf.chandef;
> -       else
> -               goto fail_rcu;
> +       } else {
> +               struct ieee80211_chanctx *ctx;
> +
> +               ctx = list_first_or_null_rcu(&local->chanctx_list,
> +                                            struct ieee80211_chanctx, list);
> +               if (!ctx ||
> +                   rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
> +                       goto fail_rcu;
> +               chandef = &ctx->conf.def;
> +       }
>
>         /*
>          * If driver/HW supports IEEE80211_CHAN_CAN_MONITOR we still
> --
> 2.54.0

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

On Wed, 2026-05-20 at 08:49 +0200, Óscar Alfonso Díaz wrote:
> Let me know if any testing of a concrete patch is needed when you feel
> it is completely fixed.

I guess Devin is saying it's fixed, and I'm saying it's the same as mine
so can't be really fixed unless something else happened in the kernel.

Do you recall which kernel version you tested with? (I don't.) Perhaps
something else in the kernel changed and it's now OK to make this
change, but we know it wasn't working when you tested before, and I'd
rather have it not work than crash.

johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Óscar Alfonso Díaz]

I tested it on 6.18.12

Let me know if you need me to test it again or whatever. I remember
during my testing with the Brite's different patches that is not the
same testing it on 6.18.x than 6.19 . Some stuff changed and the patch
needed to be different. I've added Brite to the thread, he can add
more useful data for you.

Regarding the approach of fixing the bug on the driver side... I've
emailed and contacted by IRC to Lorenzo explaining the problem... but
I got no response. So if we feel yet like this is something that needs
to be fixed from the "driver side"... how to say it softly... we are
f***ed up :) . Maybe the "hack" way dealing with the vif null var is
not bad idea after all as it seems the only way to move forward.

Let me know if somebody needs more testing.

Thanks.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El mié, 20 may 2026 a las 9:42, Johannes Berg
(<johannes@sipsolutions.net>) escribió:
>
> On Wed, 2026-05-20 at 08:49 +0200, Óscar Alfonso Díaz wrote:
> > Let me know if any testing of a concrete patch is needed when you feel
> > it is completely fixed.
>
> I guess Devin is saying it's fixed, and I'm saying it's the same as mine
> so can't be really fixed unless something else happened in the kernel.
>
> Do you recall which kernel version you tested with? (I don't.) Perhaps
> something else in the kernel changed and it's now OK to make this
> change, but we know it wasn't working when you tested before, and I'd
> rather have it not work than crash.
>
> johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

On Wed, 2026-05-20 at 10:02 +0200, Óscar Alfonso Díaz wrote:
> I tested it on 6.18.12
> 
> Let me know if you need me to test it again or whatever. I remember
> during my testing with the Brite's different patches that is not the
> same testing it on 6.18.x than 6.19 . Some stuff changed and the patch
> needed to be different. I've added Brite to the thread, he can add
> more useful data for you.

I guess I don't really care about 6.18.x or 6.19.x, only about 7.1-rcX
at this point. We'll want to explicitly _not_ backport this fix to older
kernel versions since it caused driver crashes.

> Regarding the approach of fixing the bug on the driver side... I've
> emailed and contacted by IRC to Lorenzo explaining the problem... but
> I got no response. So if we feel yet like this is something that needs
> to be fixed from the "driver side"... how to say it softly... we are
> f***ed up :) . Maybe the "hack" way dealing with the vif null var is
> not bad idea after all as it seems the only way to move forward.

I feel I've tried to say this before, but maybe it helps if I summarise:

There's one feature and one (possible) bug here.

The feature is:
 - monitor mode injection works for chanctx drivers.

The bug is:
 - monitor mode injection with the feature patch crashes at least some
   mt76 devices, which you reported, which I consider to be a bug in the
   driver that needs to be fixed there.

To me, the trade-off is crystal clear - as long as the bug exists, I'm
not going to apply this or a similar patch to enable the feature.

I'm also not going to apply a patch like proposed before that hacks it
by redirecting the vif pointer to a (more or less random) other vif,
that's a lazy hack that happens to fix the problem in your _specific_
use case, but will almost certainly still expose the crash in other use
cases.

I do think there's a chance that between 6.18/6.19 and 7.1-rcX the bug
in the driver has already been fixed, that's why I keep asking about
versions etc. But I also think there's a chance you're just testing
different subdrivers of mt76 with different devices, so I'm also asking
you to compare the specific devices.

I'm happy to apply this patch if the people who previously reported it
to crash (i.e. mostly you, not sure about others) are saying that
against a more recent kernel it no longer causes the test to crash
(rather than just not work, which is clearly better than crashing.)

You could always just claim you've tested this patch without the crash
and I'll apply it, but then if someone still finds a crash I'm just
going to have to revert it, and we'd be back to square one.

I hope this explains what I'm thinking and going to do (and not do),
make of it what you will.

johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Óscar Alfonso Díaz]

Ok, let me do one final test using Johannes’ v2 patch. The expected
behavior is as follows:

6.18 or lower: no need to test, it will not work. It’s clear now that
this does not matter, since the goal is only to fix newer kernel
versions.

6.19: some versions of the 6.19 will crash and others will not. The
crash was fixed at some point between 6.18.12 and 6.19.12. No need to
test.

7.0, or 7.1: the expected result is that there will be no crash, and
VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
(I'll test both, normal DoS and VIF+DoS). There should be no crash,
but it will not work.

So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
the results. I'll be testing this patch (v2):
https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/

Give me some time to do these tests. I'll test it on both 7.0 and 7.1 kernels.

Thanks and regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El mié, 20 may 2026 a las 10:58, Johannes Berg
(<johannes@sipsolutions.net>) escribió:
>
> On Wed, 2026-05-20 at 10:02 +0200, Óscar Alfonso Díaz wrote:
> > I tested it on 6.18.12
> >
> > Let me know if you need me to test it again or whatever. I remember
> > during my testing with the Brite's different patches that is not the
> > same testing it on 6.18.x than 6.19 . Some stuff changed and the patch
> > needed to be different. I've added Brite to the thread, he can add
> > more useful data for you.
>
> I guess I don't really care about 6.18.x or 6.19.x, only about 7.1-rcX
> at this point. We'll want to explicitly _not_ backport this fix to older
> kernel versions since it caused driver crashes.
>
> > Regarding the approach of fixing the bug on the driver side... I've
> > emailed and contacted by IRC to Lorenzo explaining the problem... but
> > I got no response. So if we feel yet like this is something that needs
> > to be fixed from the "driver side"... how to say it softly... we are
> > f***ed up :) . Maybe the "hack" way dealing with the vif null var is
> > not bad idea after all as it seems the only way to move forward.
>
> I feel I've tried to say this before, but maybe it helps if I summarise:
>
> There's one feature and one (possible) bug here.
>
> The feature is:
>  - monitor mode injection works for chanctx drivers.
>
> The bug is:
>  - monitor mode injection with the feature patch crashes at least some
>    mt76 devices, which you reported, which I consider to be a bug in the
>    driver that needs to be fixed there.
>
> To me, the trade-off is crystal clear - as long as the bug exists, I'm
> not going to apply this or a similar patch to enable the feature.
>
> I'm also not going to apply a patch like proposed before that hacks it
> by redirecting the vif pointer to a (more or less random) other vif,
> that's a lazy hack that happens to fix the problem in your _specific_
> use case, but will almost certainly still expose the crash in other use
> cases.
>
> I do think there's a chance that between 6.18/6.19 and 7.1-rcX the bug
> in the driver has already been fixed, that's why I keep asking about
> versions etc. But I also think there's a chance you're just testing
> different subdrivers of mt76 with different devices, so I'm also asking
> you to compare the specific devices.
>
> I'm happy to apply this patch if the people who previously reported it
> to crash (i.e. mostly you, not sure about others) are saying that
> against a more recent kernel it no longer causes the test to crash
> (rather than just not work, which is clearly better than crashing.)
>
> You could always just claim you've tested this patch without the crash
> and I'll apply it, but then if someone still finds a crash I'm just
> going to have to revert it, and we'd be back to square one.
>
> I hope this explains what I'm thinking and going to do (and not do),
> make of it what you will.
>
> johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

On Wed, 2026-05-20 at 11:51 +0200, Óscar Alfonso Díaz wrote:
> Ok, let me do one final test using Johannes’ v2 patch. The expected
> behavior is as follows:
> 
> 6.18 or lower: no need to test, it will not work. It’s clear now that
> this does not matter, since the goal is only to fix newer kernel
> versions.
> 
> 6.19: some versions of the 6.19 will crash and others will not. The
> crash was fixed at some point between 6.18.12 and 6.19.12. No need to
> test.
> 
> 7.0, or 7.1: the expected result is that there will be no crash, and
> VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
> (I'll test both, normal DoS and VIF+DoS). There should be no crash,
> but it will not work.
> 
> So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
> the results. I'll be testing this patch (v2):
> https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/
> 

Thanks. For testing that one you'd have to revert the other first, I
think, you could also just test this one:

https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/

But I think they're basically all equivalent.

Since we eventually need a patch to apply w/o reverting, Devin's is
probably better than my old one.

johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Óscar Alfonso Díaz]

Ok, I'll do the testing using this one you suggested:
https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/

Thanks.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El mié, 20 may 2026 a las 11:53, Johannes Berg
(<johannes@sipsolutions.net>) escribió:
>
> On Wed, 2026-05-20 at 11:51 +0200, Óscar Alfonso Díaz wrote:
> > Ok, let me do one final test using Johannes’ v2 patch. The expected
> > behavior is as follows:
> >
> > 6.18 or lower: no need to test, it will not work. It’s clear now that
> > this does not matter, since the goal is only to fix newer kernel
> > versions.
> >
> > 6.19: some versions of the 6.19 will crash and others will not. The
> > crash was fixed at some point between 6.18.12 and 6.19.12. No need to
> > test.
> >
> > 7.0, or 7.1: the expected result is that there will be no crash, and
> > VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
> > (I'll test both, normal DoS and VIF+DoS). There should be no crash,
> > but it will not work.
> >
> > So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
> > the results. I'll be testing this patch (v2):
> > https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/
> >
>
> Thanks. For testing that one you'd have to revert the other first, I
> think, you could also just test this one:
>
> https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
>
> But I think they're basically all equivalent.
>
> Since we eventually need a patch to apply w/o reverting, Devin's is
> probably better than my old one.
>
> johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Óscar Alfonso Díaz]

Hello, sorry for the delay, but here are the tests that were carried out:

-Compiled kernel 7.0.11 using the suggested patch:
https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/

*Tests with Ralink RT3572:
Standard DoS 2.4ghz -> working
VIF DoS 2.4ghz -> working
Standard DoS 5ghz -> working
VIF DoS 5ghz -> working

*Tests with MediaTek MT7921U:
Standard DoS 2.4ghz -> working
VIF DoS 2.4ghz -> working
Standard DoS 5ghz -> working
VIF DoS 5ghz -> not working (no freeze or error)

-Compiled kernel 7.1-rc6 using same patch:
https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/

*Tests with Ralink RT3572:
Standard DoS 2.4ghz -> working
VIF DoS 2.4ghz -> working
Standard DoS 5ghz -> working
VIF DoS 5ghz -> working

*Tests with MediaTek MT7921U:
Standard DoS 2.4ghz -> working
VIF DoS 2.4ghz -> working
Standard DoS 5ghz -> working
VIF DoS 5ghz -> not working (no freeze or error)

So exactly the same behavior on both kernels.

Hope it helps. Thanks and regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El mié, 20 may 2026 a las 11:55, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Ok, I'll do the testing using this one you suggested:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
>
> Thanks.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 ||
> https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
>
> El mié, 20 may 2026 a las 11:53, Johannes Berg
> (<johannes@sipsolutions.net>) escribió:
> >
> > On Wed, 2026-05-20 at 11:51 +0200, Óscar Alfonso Díaz wrote:
> > > Ok, let me do one final test using Johannes’ v2 patch. The expected
> > > behavior is as follows:
> > >
> > > 6.18 or lower: no need to test, it will not work. It’s clear now that
> > > this does not matter, since the goal is only to fix newer kernel
> > > versions.
> > >
> > > 6.19: some versions of the 6.19 will crash and others will not. The
> > > crash was fixed at some point between 6.18.12 and 6.19.12. No need to
> > > test.
> > >
> > > 7.0, or 7.1: the expected result is that there will be no crash, and
> > > VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
> > > (I'll test both, normal DoS and VIF+DoS). There should be no crash,
> > > but it will not work.
> > >
> > > So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
> > > the results. I'll be testing this patch (v2):
> > > https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/
> > >
> >
> > Thanks. For testing that one you'd have to revert the other first, I
> > think, you could also just test this one:
> >
> > https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
> >
> > But I think they're basically all equivalent.
> >
> > Since we eventually need a patch to apply w/o reverting, Devin's is
> > probably better than my old one.
> >
> > johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Óscar Alfonso Díaz]

Hi, after my yesterday's email with the tests results. As you can see,
all the cases are working but the 5ghz+VIF+DoS. Will this patch be
added anyway while looking for a fix for this specific case? if so,
from what kernel version will it be available? 7.0 I guess, just to
confirm and update airgeddon wiki-docs.

Thanks and Regards.
--
Oscar

OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--

El mar, 2 jun 2026 a las 10:29, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Hello, sorry for the delay, but here are the tests that were carried out:
>
> -Compiled kernel 7.0.11 using the suggested patch:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
>
> *Tests with Ralink RT3572:
> Standard DoS 2.4ghz -> working
> VIF DoS 2.4ghz -> working
> Standard DoS 5ghz -> working
> VIF DoS 5ghz -> working
>
> *Tests with MediaTek MT7921U:
> Standard DoS 2.4ghz -> working
> VIF DoS 2.4ghz -> working
> Standard DoS 5ghz -> working
> VIF DoS 5ghz -> not working (no freeze or error)
>
> -Compiled kernel 7.1-rc6 using same patch:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
>
> *Tests with Ralink RT3572:
> Standard DoS 2.4ghz -> working
> VIF DoS 2.4ghz -> working
> Standard DoS 5ghz -> working
> VIF DoS 5ghz -> working
>
> *Tests with MediaTek MT7921U:
> Standard DoS 2.4ghz -> working
> VIF DoS 2.4ghz -> working
> Standard DoS 5ghz -> working
> VIF DoS 5ghz -> not working (no freeze or error)
>
> So exactly the same behavior on both kernels.
>
> Hope it helps. Thanks and regards.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 ||
> https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
> El mié, 20 may 2026 a las 11:55, Óscar Alfonso Díaz
> (<oscar.alfonso.diaz@gmail.com>) escribió:
> >
> > Ok, I'll do the testing using this one you suggested:
> > https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
> >
> > Thanks.
> > --
> > Oscar
> >
> > OpenPGP Key: DA9C60E9 ||
> > https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> > 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> > --
> >
> > El mié, 20 may 2026 a las 11:53, Johannes Berg
> > (<johannes@sipsolutions.net>) escribió:
> > >
> > > On Wed, 2026-05-20 at 11:51 +0200, Óscar Alfonso Díaz wrote:
> > > > Ok, let me do one final test using Johannes’ v2 patch. The expected
> > > > behavior is as follows:
> > > >
> > > > 6.18 or lower: no need to test, it will not work. It’s clear now that
> > > > this does not matter, since the goal is only to fix newer kernel
> > > > versions.
> > > >
> > > > 6.19: some versions of the 6.19 will crash and others will not. The
> > > > crash was fixed at some point between 6.18.12 and 6.19.12. No need to
> > > > test.
> > > >
> > > > 7.0, or 7.1: the expected result is that there will be no crash, and
> > > > VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
> > > > (I'll test both, normal DoS and VIF+DoS). There should be no crash,
> > > > but it will not work.
> > > >
> > > > So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
> > > > the results. I'll be testing this patch (v2):
> > > > https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/
> > > >
> > >
> > > Thanks. For testing that one you'd have to revert the other first, I
> > > think, you could also just test this one:
> > >
> > > https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
> > >
> > > But I think they're basically all equivalent.
> > >
> > > Since we eventually need a patch to apply w/o reverting, Devin's is
> > > probably better than my old one.
> > >
> > > johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

On Wed, 2026-06-03 at 13:54 +0200, Óscar Alfonso Díaz wrote:
> Hi, after my yesterday's email with the tests results. As you can see,
> all the cases are working but the 5ghz+VIF+DoS. Will this patch be
> added anyway while looking for a fix for this specific case? if so,
> from what kernel version will it be available? 7.0 I guess, just to
> confirm and update airgeddon wiki-docs.
> 

Thanks for testing. I really don't want to have stable for this since
it's known to crash on some versions, so it'll be 7.2.

That's assuming I get a new version soon, because this one doesn't build
cleanly.

johannes

Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Johannes Berg]

On Tue, 2026-05-19 at 16:57 -0700, Devin Wittmayer wrote:
> 
> Cc: stable@vger.kernel.org # 6.9+

No. It's known to crash drivers on some versions, so it should
explicitly opt out of stable by

Cc: <stable+noautosel@kernel.org> # causes some older drivers to crash


> -	if (chanctx_conf)
> +	if (chanctx_conf) {
>  		chandef = &chanctx_conf->def;
> -	else if (local->emulate_chanctx)
> -		chandef = &local->hw.conf.chandef;
> -	else
> -		goto fail_rcu;
> +	} else {
> +		struct ieee80211_chanctx *ctx;
> +
> +		ctx = list_first_or_null_rcu(&local->chanctx_list,
> +					     struct ieee80211_chanctx, list);
> +		if (!ctx ||
> +		    rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
> +			goto fail_rcu;

This results in a sparse warning, maybe my loop approach was better
after all.

johannes

[PATCH v5 0/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

v4 [1] used list_first_or_null_rcu() plus an rcu_access_pointer() check
on the sole entry's list.next to confirm it was the only chanctx. As
Johannes pointed out [2], list.next is not an __rcu pointer, so that
check trips a sparse warning, and his original loop is cleaner. v5 walks
chanctx_list with list_for_each_entry_rcu() and takes the sole entry
instead, which builds clean.

v5 also switches the stable tag to the noautosel opt-out, since the fix
can crash older drivers and should not be auto-backported.

No functional change from v4, so the v3 Tested-by carries. I rebuilt v5
and reran the monitor injection test on mt7921e here, no crash.

[1] https://lore.kernel.org/linux-wireless/20260519235713.49109-1-lucid_duck@justthetip.ca/
[2] https://lore.kernel.org/linux-wireless/978c9a11cf836680b1fd9365f3b90f028ddf5372.camel@sipsolutions.net/

傅继晗 (1):
  wifi: mac80211: fix monitor mode frame capture for real chanctx
    drivers

 net/mac80211/tx.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

-- 
2.54.0

[PATCH v5 1/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers

[Devin Wittmayer]

From: 傅继晗 <fjhhz1997@gmail.com>

Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
behaviour") restored the monitor injection fallback for drivers using
chanctx emulation but explicitly deferred drivers that transitioned
to real chanctx ops. mt76 falls in that category and still drops
every injected frame when monitor coexists with another interface.

When the monitor has no chanctx of its own, fall back to the only
chanctx in flight if there is exactly one. Refuse if multiple are
present: picking arbitrarily would inject on an unrelated channel.
Emulated and real chanctx drivers both flow through this fallback,
since emulation always presents zero or one chanctx in
local->chanctx_list.

Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
VIF on the same phy + aireplay-ng deauth from the monitor) on
mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a
Kali VM with MT7921U passthrough as the closest match to the
original reporter's setup. None reproduced the hang seen against
the earlier attempt at this fix
(<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1
on lore in March.

Cc: <stable+noautosel@kernel.org> # causes some older drivers to crash
Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
Closes: https://github.com/morrownr/USB-WiFi/issues/682
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
v5:
  - Use list_for_each_entry_rcu() to find the single chanctx instead
    of list_first_or_null_rcu() plus an rcu_access_pointer() check on
    ctx->list.next. That field is not an __rcu pointer, so the check
    tripped a sparse warning. No functional change.
  - Opt out of stable autoselect (the fix reintroduces the crash on
    older drivers) instead of Cc: stable # 6.9+.

v4:
  - Drop the dedicated local->emulate_chanctx branch. Emulation always
    presents zero or one chanctx in local->chanctx_list, so the
    single-chanctx walk handles that path too.
  - Real-chanctx TX path is unchanged, so v3 Tested-by carries.

v3:
  - Replace list_is_singular() + list_first_entry() with an RCU walk.
    The v2 pair re-read ->next without RCU between the singularity check
    and the entry fetch, racing list_del_rcu() of the sole entry
    (rculist.h).

v2:
  - First respin under my submitter signoff; preserves fjh1997
    authorship.
  - Verification matrix; airgeddon evil-twin flow on mt7921e/mt7921u/
    Kali-VM does not reproduce the hang reported against the v1 attempt
    at this fix.

 net/mac80211/tx.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 933c86ca21c3..cf336e92c072 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2407,10 +2407,20 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 				rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
 	}
 
+	if (!chanctx_conf) {
+		struct ieee80211_chanctx *ctx;
+		bool first = true;
+
+		list_for_each_entry_rcu(ctx, &local->chanctx_list, list) {
+			if (!first)
+				goto fail_rcu;
+			chanctx_conf = &ctx->conf;
+			first = false;
+		}
+	}
+
 	if (chanctx_conf)
 		chandef = &chanctx_conf->def;
-	else if (local->emulate_chanctx)
-		chandef = &local->hw.conf.chandef;
 	else
 		goto fail_rcu;
 
-- 
2.54.0