[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,
> 傅继晗