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

Óscar Alfonso Díaz
2026-03-25T10:59:38Z

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