Kernel/iwd
3
0
Fork 0
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git synced 2024-12-18 09:12:43 +01:00
Code Releases Activity

scan: check pending requests after regdom update

Browse Source 
While there is proper handling for a regdom update during a
TRIGGER_SCAN scan, prior to NEW_SCAN_RESULTS there is no such
handling if the regdom update comes in during a GET_SCAN or
GET_SURVEY.

In both the 6ghz and non-6ghz code paths we have some issues:
  - For non-6ghz devices, or regdom updates that did not enable
    6ghz the wiphy state watch callback will automatically issues
    another GET_SURVEY/GET_SCAN without checking if there was
    already one pending. It does this using the current scan request
    which gets freed by the prior GET_SCAN/GET_SURVEY calls when
    they complete, causing invalid reads when the subsequent calls
    finish.
 - If 6ghz was enabled by the update we actually append another
   trigger command to the list and potentially run it if its the
   current request. This also will end up in the same situation as
   the request is freed by the pending GET_SURVEY/GET_SCAN calls.

For the non-6ghz case there is little to no harm in ignoring the
regdom update because its very unlikely it changed the allowed
frequencies.

For the 6ghz case we could potentially handle the new trigger scan
within get_scan_done, but thats beyond the scope of this change
and is likely quite intrusive.
This commit is contained in:
James Prestwood 2024-09-05 08:26:58 -07:00 committed by Denis Kenzior
parent 3bc8b90c0e
commit 3f06d0128a
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/scan.c
View File

@ -2121,6 +2121,22 @@ static void scan_wiphy_watch(struct wiphy *wiphy,
if (!sr)
return;
/*
* If the regdom update finished with GET_SCAN/GET_SURVEY in flight
* don't try and get the results again and allow those calls to finish.
* For the non-6ghz case this has no downside as the results should not
* differ.
*
* If 6ghz was enabled by this regdom update there is still not much we
* can do since the scan itself is already completed. Appending to the
* command list won't do anything.
*
* TODO: Handle the 6ghz case by checking for this case in get_scan_done
* and continuing to iterate the sr->cmds array.
*/
if (sc->get_scan_cmd_id || sc->get_survey_cmd_id)
return;
/*
* This update did not allow 6GHz, or the original request was
* not expecting 6GHz. The periodic scan should now be ended.