Avoid sched scan flood in case of mismatched security (UPSTREAM)

Current sched scan in the kernel is limited to SSID matching.
A rare corner case is when an AP with a matching SSID but unmatching
security to a saved profile is in the vicinity. In such a case
sched scan results will immediately be returned after initiating sched
scan however no match will be found due to the security mismatch.
This goes on in a tight loop which is bad as it will effectively
prevent the host from suspending and scan results will eventually
contain the single AP matched by the sched scan due to expiration
of other APs scanned in normal scans which are less frequent.

Avoid this by stopping sched scan after detecting sched scan results
were received but no matched network. Don't start another sched
scan immediately but wait for the next normal scan without any results
to restart it. This prevents the tight loop.

Signed-off-by: Eyal Shapira <eyal@wizery.com>

1 files changed, 13 insertions, 2 deletions

diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
index 7f46a4f..c735da3 100644
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -1232,9 +1232,20 @@ static int _wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s,
 				return 0;
 			}
 #endif /* CONFIG_P2P */
-			if ((data && data->scan_info.is_sched_scan_res) ||
-			    !wpa_s->sched_scanning)
+			/*
+			 * If sched scan results were received but we didn't
+			 * connect then there's an AP with a matching SSID
+			 * which may have mismatching security. Don't restart
+			 * another sched scan immediately and wait for the next
+			 * normal scan in scan_interval to trigger it in order
+			 * to avoid a sched scan results storm.
+			 * In any case if it's not started kick start it.
+			 */
+			if (!wpa_s->sched_scanning)
 				wpa_supplicant_req_sched_scan(wpa_s);
+			else if (data && data->scan_info.is_sched_scan_res)
+				wpa_supplicant_cancel_sched_scan(wpa_s);
+
 			wpa_supplicant_req_new_scan(wpa_s, timeout_sec,
 						    timeout_usec);
 		}