[PATCH] wifi: mac80211: prevent destroying non-TDLS stations in TDLS operations

[PATCH] wifi: mac80211: prevent destroying non-TDLS stations in TDLS operations

[syzbot]

From: Krystian Kaniewski <krystianmkaniewski@gmail.com>

When userspace sends a NL80211_CMD_TDLS_OPER command with the
NL80211_TDLS_DISABLE_LINK operation, the request is handled by
ieee80211_tdls_oper(). The code for this operation directly calls
sta_info_destroy_addr() to destroy the station entry associated with the
provided MAC address. Unlike the NL80211_TDLS_ENABLE_LINK case, which
correctly verifies that the target station exists and is actually a TDLS
peer, the disable link path blindly destroys whatever station matches the
MAC address.

If the provided MAC address is the AP's MAC address, this causes the AP's
station entry to be destroyed while the interface is still associated.
Later, when the driver attempts to send a probe request to the AP, it looks
up the AP's station entry, which returns NULL, triggering a warning in
ieee80211_mgd_probe_ap_send():

WARNING: net/mac80211/mlme.c:4898 at
ieee80211_mgd_probe_ap_send+0x497/0x560 net/mac80211/mlme.c:4898
RIP: 0010:ieee80211_mgd_probe_ap_send+0x497/0x560 net/mac80211/mlme.c:4898
Call Trace:
 <TASK>
 cfg80211_wiphy_work+0x29e/0x420 net/wireless/core.c:538
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

A similar issue exists in ieee80211_tdls_peer_del_work() which is queued by
ieee80211_tdls_mgmt_setup(). If a TDLS setup request is sent with the AP's
MAC address, the AP's station entry will be destroyed when the setup
timeout expires.

Fix this by explicitly verifying that the station exists and is a TDLS peer
(sta->sta.tdls == true) before destroying it in both ieee80211_tdls_oper()
and ieee80211_tdls_peer_del_work().

Fixes: dfe018bf9953 ("mac80211: handle TDLS high-level commands and frames")
Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+a59b5291776979816910@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a59b5291776979816910
Link: https://syzkaller.appspot.com/ai_job?id=986e342d-a720-47ab-84bf-e8be0e8b70e5
Signed-off-by: Krystian Kaniewski <krystianmkaniewski@gmail.com>

---
diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c
index ffd575a8d..eef1dde1c 100644
--- a/net/mac80211/tdls.c
+++ b/net/mac80211/tdls.c
@@ -33,8 +33,12 @@ void ieee80211_tdls_peer_del_work(struct wiphy *wiphy, struct wiphy_work *wk)
 	lockdep_assert_wiphy(local->hw.wiphy);
 
 	if (!is_zero_ether_addr(sdata->u.mgd.tdls_peer)) {
+		struct sta_info *sta;
+
 		tdls_dbg(sdata, "TDLS del peer %pM\n", sdata->u.mgd.tdls_peer);
-		sta_info_destroy_addr(sdata, sdata->u.mgd.tdls_peer);
+		sta = sta_info_get(sdata, sdata->u.mgd.tdls_peer);
+		if (sta && sta->sta.tdls)
+			sta_info_destroy_addr(sdata, sdata->u.mgd.tdls_peer);
 		eth_zero_addr(sdata->u.mgd.tdls_peer);
 	}
 }
@@ -1462,6 +1466,10 @@ int ieee80211_tdls_oper(struct wiphy *wiphy, struct net_device *dev,
 			     !ether_addr_equal(sdata->u.mgd.tdls_peer, peer));
 		break;
 	case NL80211_TDLS_DISABLE_LINK:
+		sta = sta_info_get(sdata, peer);
+		if (!sta || !sta->sta.tdls)
+			return -ENOLINK;
+
 		/*
 		 * The teardown message in ieee80211_tdls_mgmt_teardown() was
 		 * created while the queues were stopped, so it might still be
@@ -1476,7 +1484,7 @@ int ieee80211_tdls_oper(struct wiphy *wiphy, struct net_device *dev,
 		/* flush a potentially queued teardown packet */
 		ieee80211_flush_queues(local, sdata, false);
 
-		ret = sta_info_destroy_addr(sdata, peer);
+		ret = __sta_info_destroy(sta);
 
 		iee80211_tdls_recalc_ht_protection(sdata, NULL);
 


base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff
-- 
See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
You can comment on the patch as usual, syzbot will try to address
the comments and send a new version of the patch if necessary.
syzbot engineers can be reached at syzkaller@googlegroups.com.

sysbot AI patches and wireless

[Johannes Berg]

Hi,

> See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
> You can comment on the patch as usual, syzbot will try to address
> the comments and send a new version of the patch if necessary.

I'm going to state, for the record, that I'm going to make judicious use
of ability to ignore patches, and apply it to pretty much all syzbot-AI-
generated patches unless a 3-second review says "obviously right".

In particular, I will absolutely *not* "comment on the patches as usual"
and argue with an LLM that can bullshit out code faster than another
computer can even deliver it to me by email.

Whoever is currently pretending to be the human in the loop *absolutely*
needs to think about the patches, and if that's happening it's probably
no longer an AI-generated-sent-by-syzbot but you're going to rewrite it
and send it properly.

(IOW: get lost, syzbot)

johannes

Re: sysbot AI patches and wireless

[Aleksandr Nogikh]

Hi Johannes,

Thanks for reaching out!

On Thu, Aug 6, 2026 at 9:57 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi,
>
> > See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
> > You can comment on the patch as usual, syzbot will try to address
> > the comments and send a new version of the patch if necessary.
>
> I'm going to state, for the record, that I'm going to make judicious use
> of ability to ignore patches, and apply it to pretty much all syzbot-AI-
> generated patches unless a 3-second review says "obviously right".
>
> In particular, I will absolutely *not* "comment on the patches as usual"
> and argue with an LLM that can bullshit out code faster than another
> computer can even deliver it to me by email.

Some clarifications to prevent misunderstanding:

1. Every AI-generated patch sent by syzbot has been pre-reviewed and
approved by a human engineer. The person who approved the patch is
listed in the From: and Signed-off-by: fields.
You can see this pre-review process on our moderation mailing list:
https://groups.google.com/g/syzkaller-upstream-moderation/search?q=patch%20wireless

2. For the patches already sent to LKML, the bot *does not* send
automatic replies and *does not* automatically submit newer versions.
Once the patch is on LKML, follow-ups, comments, and iterations are
handled entirely by the human developer who signed off on it, so you
have not been interacting with an LLM.

I apologize for the frustration this may have caused. We'll stop
sending AI-assisted patches to the wireless subsystem.

-- 
Aleksandr

>
> Whoever is currently pretending to be the human in the loop *absolutely*
> needs to think about the patches, and if that's happening it's probably
> no longer an AI-generated-sent-by-syzbot but you're going to rewrite it
> and send it properly.
>
> (IOW: get lost, syzbot)
>
> johannes
>

Re: sysbot AI patches and wireless

[Johannes Berg]

Hi!

> 1. Every AI-generated patch sent by syzbot has been pre-reviewed and
> approved by a human engineer. The person who approved the patch is
> listed in the From: and Signed-off-by: fields.

Yes, I realize that. But the experience still seems to be one of me
effectively consuming pure LLM output, just via an intermediary. If I
had the time to do that, then I'd be perfectly able to talk to an LLM
directly, cutting out the intermediaries, and get the issues fixed that
way - much, much faster than writing everything in emails.

If, on the other hand, the intermediaries actually do the necessary
legwork etc. then I don't think this whole process is necessary; I don't
think using "b4" would be a significant hurdle in the process, and
that's really the only thing this helps with? Maybe LLM access (not
everyone has effectively free tokens), but that's still enabled by
syzbot providing the service over on the internal/upstream-moderation
list I guess.

Now, of course now that I say this (and you disabled it) I guess I'll
just see the patches pasted into an email manually instead, and I've
lost the signal that I could use to just ignore them entirely, but at
least I've been honest about it - and I guess I'll still silently drop
patches where the "human engineer" has no idea what they're doing. Even
having Reported-by: syzbot has been a signal of that to some extent.

I do think syzbot is a bit of a special case - at least if there's a
reproducer it's trivial to tell the system "hack the code until the
issue no longer reproduces" - but that's almost certainly guaranteed to
not be a useful patch yet.

The system, in a case like this, is almost certainly going to provide a
very narrow, targeted fix (with an annoying wall of text explaining
exactly that), but I think that at least the human in the loop should
actually take a step back from that and ask what the semantics of the
code should be ... I've played this game with Slawomir's first patch
myself, but that clearly cannot scale if the original intermediary
doesn't want to do that.

Maybe it's something you can even tell the LLM to do, somehow, so the
first draft is better. In this case, for example, why the hell did it
decide that it made any sense to have multiple branches of the same
switch statement - and there are even only two! - implement the same
validation? At the very least I'd expect the "human engineer" to take
that step back.

This is why I'm refusing these patches, because clearly nobody actually
even bothers to look at the semantics of the code before or during the
patching. Does pulling out the check outside of the switch change the
order of errors? Yes. Does that matter? No, the new order of errors for
NL80211_TDLS_ENABLE_LINK would actually - if you think about it (!) -
make a lot more sense! Am I surprised the LLM doesn't do that when you
tell it to make a targeted fix? Absolutely not.

But I really cannot make that judgement call myself for every single
issue like that, if I could, see above, I could be doing all of this
myself. Need the contributors to do that. Slawomir did that after I
prompted (pun intended!) him to do that, and it didn't work out so well
and we had a good discussion about it, but again, I can't provide that
support all time.

> 2. For the patches already sent to LKML, the bot *does not* send
> automatic replies and *does not* automatically submit newer versions.
> Once the patch is on LKML, follow-ups, comments, and iterations are
> handled entirely by the human developer who signed off on it, so you
> have not been interacting with an LLM.

Thanks for clarifying. I've definitely seen pure LLM replies (sometimes
even with the output saying things along the lines of "the reviewer said
this, I'll explain...") but that might have been in other contexts,
clearly it's not just syzbot which enables people doing things like
that.

> I apologize for the frustration this may have caused. We'll stop
> sending AI-assisted patches to the wireless subsystem.

Apology accepted, and thanks for disabling it.

Slawomir, Krystian, I assume you mean well and I apologise that you're
getting caught in the cross-fire here. Even the targeted fixes are still
fixes, so I understand from your perspective this still made sense, but
from mine it just absolutely cannot scale, both in terms of long-term
maintenance (sprinkling checks all over the code disregarding the
architecture) and also in terms of review bandwidth etc. I'm sorry
you're effectively the two first victims of this new process.

johannes

Re: sysbot AI patches and wireless

[Slawomir Stepien]

On sie 06, 2026 12:15, Johannes Berg wrote:
> Hi!
> 
> > 1. Every AI-generated patch sent by syzbot has been pre-reviewed and
> > approved by a human engineer. The person who approved the patch is
> > listed in the From: and Signed-off-by: fields.
> 
> Yes, I realize that. But the experience still seems to be one of me
> effectively consuming pure LLM output, just via an intermediary. If I
> had the time to do that, then I'd be perfectly able to talk to an LLM
> directly, cutting out the intermediaries, and get the issues fixed that
> way - much, much faster than writing everything in emails.
> 
> If, on the other hand, the intermediaries actually do the necessary
> legwork etc. then I don't think this whole process is necessary; I don't
> think using "b4" would be a significant hurdle in the process, and
> that's really the only thing this helps with? Maybe LLM access (not
> everyone has effectively free tokens), but that's still enabled by
> syzbot providing the service over on the internal/upstream-moderation
> list I guess.
> 
> Now, of course now that I say this (and you disabled it) I guess I'll
> just see the patches pasted into an email manually instead, and I've
> lost the signal that I could use to just ignore them entirely, but at
> least I've been honest about it - and I guess I'll still silently drop
> patches where the "human engineer" has no idea what they're doing. Even
> having Reported-by: syzbot has been a signal of that to some extent.
> 
> I do think syzbot is a bit of a special case - at least if there's a
> reproducer it's trivial to tell the system "hack the code until the
> issue no longer reproduces" - but that's almost certainly guaranteed to
> not be a useful patch yet.
> 
> The system, in a case like this, is almost certainly going to provide a
> very narrow, targeted fix (with an annoying wall of text explaining
> exactly that), but I think that at least the human in the loop should
> actually take a step back from that and ask what the semantics of the
> code should be ... I've played this game with Slawomir's first patch
> myself, but that clearly cannot scale if the original intermediary
> doesn't want to do that.
> 
> Maybe it's something you can even tell the LLM to do, somehow, so the
> first draft is better. In this case, for example, why the hell did it
> decide that it made any sense to have multiple branches of the same
> switch statement - and there are even only two! - implement the same
> validation? At the very least I'd expect the "human engineer" to take
> that step back.
> 
> This is why I'm refusing these patches, because clearly nobody actually
> even bothers to look at the semantics of the code before or during the
> patching. Does pulling out the check outside of the switch change the
> order of errors? Yes. Does that matter? No, the new order of errors for
> NL80211_TDLS_ENABLE_LINK would actually - if you think about it (!) -
> make a lot more sense! Am I surprised the LLM doesn't do that when you
> tell it to make a targeted fix? Absolutely not.
> 
> But I really cannot make that judgement call myself for every single
> issue like that, if I could, see above, I could be doing all of this
> myself. Need the contributors to do that. Slawomir did that after I
> prompted (pun intended!) him to do that, and it didn't work out so well

It didn't? Or it did? :) Well I do not have new version of the patch yet, but I'm still
investigating correct approach and testing a lot. I see now, that I should do that in the 1st place.
I'm sorry for that.

> and we had a good discussion about it, but again, I can't provide that
> support all time.
> 
> > 2. For the patches already sent to LKML, the bot *does not* send
> > automatic replies and *does not* automatically submit newer versions.
> > Once the patch is on LKML, follow-ups, comments, and iterations are
> > handled entirely by the human developer who signed off on it, so you
> > have not been interacting with an LLM.
> 
> Thanks for clarifying. I've definitely seen pure LLM replies (sometimes
> even with the output saying things along the lines of "the reviewer said
> this, I'll explain...") but that might have been in other contexts,
> clearly it's not just syzbot which enables people doing things like
> that.
> 
> > I apologize for the frustration this may have caused. We'll stop
> > sending AI-assisted patches to the wireless subsystem.
> 
> Apology accepted, and thanks for disabling it.
> 
> Slawomir, Krystian, I assume you mean well and I apologise that you're
> getting caught in the cross-fire here. Even the targeted fixes are still
> fixes, so I understand from your perspective this still made sense, but
> from mine it just absolutely cannot scale, both in terms of long-term
> maintenance (sprinkling checks all over the code disregarding the
> architecture) and also in terms of review bandwidth etc. I'm sorry
> you're effectively the two first victims of this new process.

Thanks and now worries! It's a good lesson, that the overall subsystem might need a better
approach. I know, that I sometimes will overlook this.

In the end, I should be saying sorry for wasting your time. And also, I should say `thanks!` for all
the good hints and "prompts"!

-- 
Slawomir Stepien

Re: sysbot AI patches and wireless

[Johannes Berg]

Hi Slawomir,

> > But I really cannot make that judgement call myself for every single
> > issue like that, if I could, see above, I could be doing all of this
> > myself. Need the contributors to do that. Slawomir did that after I
> > prompted (pun intended!) him to do that, and it didn't work out so well
> 
> It didn't? Or it did? :)

Sorry, indeed, it *did* - thank you.

> Well I do not have new version of the patch yet, but I'm still
> investigating correct approach and testing a lot. I see now, that I should do that in the 1st place.
> I'm sorry for that.

No worries.

This in just after our exchange here:

https://lore.kernel.org/ksummit/87y0ekm9nw.fsf@trenco.lwn.net/

It's definitely part of the job to train new contributors, and it's
actually very rewarding to see someone grow from first time contributor.
Sadly, now there's basically no "first-contact signal" that says "I care
about this more than landing this one patch". :-/ Getting a well-formed
(and well-argued) patch used to be worth something, now it's basically
not.

See also Dan's "pair programming" reply.

But I see the other side too; my first patch to the kernel, more than
two decades ago, was a similar thing, though argued first over IRC.
People need a support community to start out anywhere.

Also, I think with patches part of the issue is that there's an implicit
assumption that it'll get reviewed/merged/etc. - but as a submitter you
don't really have anyone to ask questions about that patch and process
before sending (unless you were hired into a Linux team or something).

I obviously don't have a solution to this - I'm just honestly stating
that it doesn't scale for me as the maintainer to be providing this,
certainly not in the format that syzbot's patch-as-a-service encourages,
but more generally also not. A few new folks per year is fine, a few per
month can't work.

Some people hang out on IRC (#linux-wireless, myself too), some people
build experience in other communities like OpenWRT first (or just remain
there), etc. Part of the issue is that we haven't _really_ documented
any of this as the wireless or even broader kernel community, but things
also shift frequently anyway. Another part is - not saying that's the
case for you - that some people just don't care and all they want is
land patches, so they'll go across subsystems, never learn one, and just
hope something sticks somewhere.

Meanwhile, I hope you're not too discouraged by all this, again, sorry
you got caught in the cross-fire here. (I'm going to be on vacation, we
can pick up the thread about your specific patches in September.)

johannes

Re: sysbot AI patches and wireless

[Hillf Danton]

On Thu, 06 Aug 2026 16:49:45 +0200 Johannes Berg wrote:
>
> It's definitely part of the job to train new contributors, and it's
> actually very rewarding to see someone grow from first time contributor.
> Sadly, now there's basically no "first-contact signal" that says "I care
> about this more than landing this one patch". :-/ Getting a well-formed
> (and well-argued) patch used to be worth something, now it's basically not.
>
Nope, who cares (LPC/Unix)?
Is Linux helping make the earth a better place (for who/all)?