linux-kernel - Re: [PATCH wireless-next v3] wifi: mac80211: consider links for validating SCAN_FLAG

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: <f5148f63e6f96fd18558dbb7f49d090aec931745.camel@sipsolutions.net>
Date: Tue, 08 Jul 2025 12:46:53 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Aditya Kumar Singh <aditya.kumar.singh@....qualcomm.com>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH wireless-next v3] wifi: mac80211: consider links for
 validating SCAN_FLAG_AP in scan request during MLO

On Wed, 2025-06-25 at 18:31 +0530, Aditya Kumar Singh wrote:
> 
> -		if (ieee80211_num_beaconing_links(sdata) &&
> -		    (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
> -		     !(req->flags & NL80211_SCAN_FLAG_AP)))
> -			return -EOPNOTSUPP;
> +		for (link_id = 0; link_id < IEEE80211_MLD_MAX_NUM_LINKS;
> +		     link_id++) {
> +			link = sdata_dereference(sdata->link[link_id], sdata);
> +			if (!link)
> +				continue;

for_each_link_data()

> +
> +			/* if the link is not beaconing, ignore it */
> +			if (!sdata_dereference(link->u.ap.beacon, sdata))
> +				continue;
> +
> +			/* If we are here then at least one of the link is
> +			 * beaconing and since radio level information is
> +			 * not present or single underlying radio is present,
> +			 * no point in checking further and hence return if
> +			 * flag requirements are not met.
> +			 */
> +			if (wiphy->n_radio < 2) {
> +				if (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
> +				    !(req->flags & NL80211_SCAN_FLAG_AP))
> +					return -EOPNOTSUPP;
> +
> +				continue;
> +			}

Is that _really_ worth special-casing in the scan control path? It's not
like this is a performance question here.

Maybe ieee80211_is_radio_idx_in_scan_req() shouldn't WARN_ON() then or
something, so we can reuse it. Or maybe (better?) just reorder the
checks there, if the chan_radio_idx==-1 and radio_idx==-1 would return
first, and WARN only if we found a scan channel that isn't covered by a
radio?

And <2 seems really strange anyway, ==1 should basically never happen,
it's equivalent to ==0, as in no list of radios?

johannes