From 3f06d0128ad23f3426674f21af8f6d1039fb388d Mon Sep 17 00:00:00 2001 From: James Prestwood Date: Thu, 5 Sep 2024 08:26:58 -0700 Subject: [PATCH] scan: check pending requests after regdom update 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. --- src/scan.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/scan.c b/src/scan.c index 1cec9785..2ffbef6d 100644 --- a/src/scan.c +++ b/src/scan.c @@ -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.