CVE-2026-68469 in Linux
Riassunto
di VulDB • 15/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
wifi: mwifiex: corregge le scansioni permanentemente occupate dopo multiple iterazioni di roaming
Affinché il firmware possa entrare in modalità sleep, il driver deve confermare una richiesta di sleep precedentemente ricevuta. La sequenza normale degli eventi procede come segue: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> conferma-sleep (sleep-confirm) -> SLEEP -> EVENT_AWAKE -> AWAKE.
Prima di inviare il comando di conferma-sleep, il driver deve assicurarsi che non vi siano comandi in esecuzione o in attesa di completamento.
mwifiex_ret_802_11_associate() imposta incondizionatamente ps_state = PS_STATE_AWAKE quando elabora la risposta al comando di associazione, al di fuori del flusso normale di gestione della modalità risparmio energetico (powersave). Se arriva EVENT_SLEEP mentre il comando di associazione è in transito, ps_state risulta essere PRE_SLEEP quando viene analizzata la risposta al comando di associazione e l'imposizione forzata di AWAKE sovrascrive tale valore. La conferma-sleep differita non viene mai inviata.
Un successivo comando scan_start viene correttamente riconosciuto (acknowledged), ma il firmware non genera eventi scan_result. La richiesta di scansione non termina mai e le richieste aggiuntive dall'userspace falliscono con -EBUSY.
Dopo aver effettuato test su entrambi i dispositivi IW412 e W8997, sono riuscito a innescare il bug solo sull'IW412 ed ho osservato che i firmware si comportano in modo diverso. Sull'IW412 il firmware invia ancora EVENT_SLEEP mentre è in corso il processo di autenticazione/associazione. Un dispositivo W8997 nelle stesse condizioni sembra sopprimere la modalità powersave per tutta la durata dell'associazione, quindi PRE_SLEEP non coincide mai con la risposta all'associazione anche dopo periodi prolungati di test utilizzando i loop descritti di seguito (>12 ore).
Sull'IW412, il ritardo tra i comandi che innesca un EVENT_SLEEP è stato determinato empiricamente essere di circa 20ms. Questo ritardo può verificarsi naturalmente quando il driver sta generando informazioni di debug (debug_mask = 0x00000037), situazione nella quale il problema delle scansioni occupate è ripetibile durante l'esecuzione del "test 1)" come descritto di seguito. Se il ritardo tra i comandi è inferiore a circa 20ms, il firmware rimane sveglio e il problema non era riproducibile eseguendo lo stesso test.
Il percorso host_mlme=false si comporta in modo diverso. In questo caso, l'intera transazione di autenticazione/associazione viene eseguita da un singolo comando (HostCmd_CMD_802_11_ASSOCIATE) e il firmware non emette EVENT_SLEEP mentre il comando è in esecuzione.
Rimuovere l'assegnazione in modo che ps_state venga manipolato solo nei percorsi correlati alla gestione degli eventi di powersave e nel workqueue principale per una corretta conferma del sleep.
Sono stati eseguiti i seguenti test a loop (con output di debug abilitato): 1) forzare il roaming tra due AP, uno 5GHz e uno 2.4GHz, con lo stesso SSID. Utilizzare wpa_cli per innescare il comportamento di roaming, attendere 2 secondi tra le iterazioni. 2) forzare la disconnessione dall'AP 1 e la connessione all'AP 2, testare la scansione. Utilizzare wpa_cli per innescare i cambiamenti di connessione, attendere 2 secondi tra le iterazioni.
Ogni test è stato eseguito su ciascun dispositivo per almeno 3 ore.
If you want to get best quality of vulnerability data, you may have to visit VulDB.