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

["Óscar Alfonso Díaz" <oscar.alfonso.diaz@gmail.com>]

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