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@xxxxxxxxxxxxx>) escribió:
>
> From: 傅继晗 <fjhhz1997@xxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxxx>) or against v1
> on lore in March.
>
> Cc: stable@xxxxxxxxxxxxxxx # 6.9+
> Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@xxxxxxxxx>
> Closes: https://github.com/morrownr/USB-WiFi/issues/682
> Tested-by: Devin Wittmayer <lucid_duck@xxxxxxxxxxxxx>
> Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
> Signed-off-by: 傅继晗 <fjhhz1997@xxxxxxxxx>
> Signed-off-by: Devin Wittmayer <lucid_duck@xxxxxxxxxxxxx>
> ---
> 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