linux-kernel - Re: [PATCH wireless-next 2/3] wifi: mac80211: Allow scan on a radio while operating on DFS on another radio

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] [day] [month] [year] [list]

Message-ID: <987b6a9a-4292-466b-b2f2-dc0302dff1f3@quicinc.com>
Date: Tue, 27 May 2025 12:19:10 +0530
From: Raj Kumar Bhagat <quic_rajkbhag@...cinc.com>
To: Johannes Berg <johannes@...solutions.net>
CC: <linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH wireless-next 2/3] wifi: mac80211: Allow scan on a radio
 while operating on DFS on another radio

On 5/22/2025 4:53 PM, Johannes Berg wrote:
>>>> +	for (i = 0; i < scan_req->n_channels; i++) {
>>>> +		chan = scan_req->channels[i];
>>>> +		chan_radio_idx = cfg80211_get_radio_idx_by_chan(wiphy, chan);
>>>> +		/*
>>>> +		 * Skip channels with an invalid radio index and continue
>>>> +		 * checking. If any channel in the scan request matches the
>>>> +		 * given radio index, return true.
>>>> +		 */
>>>> +		if (chan_radio_idx < 0)
>>>> +			continue;
>>> This seems ... wrong? If there's a channel in the scan request that
>>> didn't map to _any_ radio then how are we even scanning there? And the
>>> comment seems even stranger, why would we _want_ to ignore it (which it
>>> conveniently doesn't answer)?
>>>
>> It seems, (chan_radio_idx < 0) should never be true because the chan is
>> taken from the valid scan request. I should remove this check in next version?
> I'm not sure, why did you add it? Maybe it should be a WARN_ON and abort
> the whole function? It just doesn't seem right to _ignore_.

I initially added the check as a precautionary measure.

In the next version, I’ll replace it with a WARN_ON() to flag the unexpected
condition. As a conservative approach, will return true in that case, assuming
the scan request might use the specified radio_idx to safely abort the function.