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

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

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

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

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

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

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.

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

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