linux-kernel - Re: [PATCH v3] wifi: mac80211: Prevent disconnect reports when no AP is associated

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <89dd111db62029f1575f7a7113e2a0cb5a1a8d5f.camel@sipsolutions.net>
Date: Tue, 24 Jun 2025 15:35:55 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Zhongqiu Han <quic_zhonhan@...cinc.com>, 
	miriam.rachel.korenblit@...el.com
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org, 
	syzbot+5a7b40bcb34dea5ca959@...kaller.appspotmail.com
Subject: Re: [PATCH v3] wifi: mac80211: Prevent disconnect reports when no
 AP is associated

> > 
> > >    - Remove WARN_ON and early return in ieee80211_report_disconnect()
> > >    - Change the return type of ieee80211_set_disassoc(). If
> > >      ieee80211_report_disconnect() uses the frame_buf initialized by
> > >      ieee80211_set_disassoc(), its invocation is now conditional based
> > >      on the return value of ieee80211_set_disassoc().
> > 
> > I don't understand this change ... surely syzbot couldn't have run into
> > an uninitialized buffer after the WARN_ON since it has panic_on_warn. So
> > why all these changes:
> 
> yes, syzbot couldn't have run into an uninitialized buffer after the
> WARN_ON on **patch v2** such as:
> 
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -4433,6 +4433,10 @@ static void ieee80211_report_disconnect(struct 
> ieee80211_sub_if_data *sdata,
>   		.u.mlme.data = tx ? DEAUTH_TX_EVENT : DEAUTH_RX_EVENT,
>   		.u.mlme.reason = reason,
>   	};
> +	struct sta_info *ap_sta = sta_info_get(sdata, sdata->vif.cfg.ap_addr);
> +
> +	if (WARN_ON(!ap_sta))
> +		return;

I think you misunderstood ... We have this WARN_ON since 687a7c8a7227
("wifi: mac80211: change disassoc sequence a bit"). Therefore, !ap_sta
cannot be the cause of syzbot complaints, since WARN_ON would panic it
before it ever gets to the uninitialized memory use.


> "You're adding a WARN_ON() that's now guaranteed to trigger, no

so now it's no longer your WARN_ON, I guess, but how did it trigger? I
really think we need to figure out how it triggered and fix _that_.

johannes