CVE-2026-68469 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
wifi: mwifiex: Behebung von dauerhaft busy-Scans nach mehreren Roaming-Iterationen
Damit der Firmware-Schlafmodus aktiviert werden kann, muss der Treiber eine zuvor empfangene Sleep-Anfrage bestätigen. Die normale Abfolge der Ereignisse sieht wie folgt aus: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE.
Vor dem Senden des sleep-confirm-Befehls muss sichergestellt werden, dass keine Befehle entweder gerade ausgeführt oder noch in der Warteschlange auf Abschluss stehen.
mwifiex_ret_802_11_associate() setzt ps_state = PS_STATE_AWAKE bedingungslos zurück, wenn es die Antwort des Assoziationsbefehls verarbeitet, außerhalb des normalen Powersave-Management-Ablaufs. Wenn EVENT_SLEEP eintrifft, während der Assoziationsbefehl noch in Bearbeitung ist (in flight), ist ps_state PRE_SLEEP, wenn die Antwort auf den Assoziationsbefehl analysiert wird, und das erzwungene AWAKE überschreibt diesen Wert. Die verschobene sleep-confirm-Nachricht wird niemals gesendet.
Ein nachfolgender scan_start-Befehl wird korrekt bestätigt, aber der Firmware generiert keine scan_result-Ereignisse. Der Scanvorgang endet nie, und zusätzliche Anfragen von userspace schlagen mit -EBUSY fehl.
Nach Tests auf beiden Geräten IW412 und W8997 konnte ich den Fehler nur am IW412 auslösen und beobachtete unterschiedliches Verhalten der Firmwares. Beim IW412 sendet die Firmware weiterhin EVENT_SLEEP, während der Authentifizierungs-/Assoziationsprozess noch läuft. Ein W8997 unter denselben Bedingungen scheint Powersave für die Dauer der Assoziation zu unterdrücken, sodass PRE_SLEEP nie mit der Antwort auf die Assozisation zusammenfiel, selbst nach ausgedehnten Testperioden (>12 Stunden) mit den unten beschriebenen Schleifen.
Beim IW412 wurde die Verzögerung zwischen Befehlen, die ein EVENT_SLEEP auslöst, empirisch auf ~20 ms bestimmt. Diese Verzögerung kann natürlich auftreten, wenn der Treiber Debug-Informationen ausgibt (debug_mask = 0x00000037), in welcher Situation das Problem mit den busy scans wiederholbar ist, während „Test 1)“ wie unten beschrieben ausgeführt wird. Wenn die Verzögerung zwischen Befehlen weniger als ~20 ms beträgt, bleibt die Firmware wach und der Fehler war bei Ausführung desselben Tests nicht reproduzierbar.
Der Pfad host_mlme=false verhält sich ebenfalls anders. In diesem Fall wird die gesamte Authentifizierungs-/Assoziations-Transaktion von einem einzigen Befehl (HostCmd_CMD_802_11_ASSOCIATE) ausgeführt, und die Firmware sendet kein EVENT_SLEEP, während der Befehl läuft.
Entfernen Sie die Zuweisung, damit ps_state nur in den Pfaden manipuliert wird, die mit der Verarbeitung von Powersave-Ereignissen zusammenhängen, sowie im Haupt-Workqueue für eine korrekte Sleep-Bestätigung.
Die folgenden Schleifentests wurden durchgeführt (mit aktivierter Debug-Ausgabe): 1) Erzwingen des Roamings zwischen zwei APs, einem 5-GHz und einem 2,4-GHz mit derselben SSID. Verwenden Sie wpa_cli, um das Roaming-Verhalten auszulösen, Sleep von 2 s zwischen den Iterationen. 2) Erzwingen einer Trennung zu AP 1 und einer Verbindung zu AP 2, Scan-Test. Verwenden Sie wpa_cli, um die Verbindungsänderungen auszulösen, Sleep von 2 s zwischen den Iterationen.
Jeder Test wurde auf jedem Gerät für mindestens 3 Stunden ausgeführt.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.