CVE-2026-68469 in Linux
Sumário
de VulDB • 15/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
wifi: mwifiex: corrige varreduras permanentemente ocupadas após múltiplas iterações de roaming
Para que o firmware entre em modo de suspensão (sleep), o driver deve confirmar um pedido de suspensão recebido anteriormente. A sequência normal de eventos é a seguinte: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Antes de enviar o comando sleep-confirm, o driver deve garantir que não há comandos em execução ou aguardando conclusão.
mwifiex_ret_802_11_associate() define incondicionalmente ps_state = PS_STATE_AWAKE ao processar a resposta do comando de associação, fora do fluxo normal de gerenciamento de powersave (economia de energia). Se EVENT_SLEEP chegar enquanto o comando de associação estiver em trânsito, ps_state será PRE_SLEEP quando a resposta do comando de associação for analisada, e a sobrescrita forçada para AWAKE substituirá esse valor. O sleep-confirm diferido nunca é enviado.
Um comando scan_start subsequente é corretamente reconhecido, mas o firmware não gera eventos scan_result. A solicitação de varredura nunca termina, e solicitações adicionais do userspace falham com -EBUSY.
Após testes tanto no IW412 quanto no W8997, consegui acionar o bug apenas no IW412 e observei que os firmwares se comportam diferentemente. No IW412, o firmware ainda envia EVENT_SLEEP enquanto o processo de autenticação/associação está em andamento. Um W8997 nas mesmas condições parece suprimir o powersave durante a duração da associação, portanto PRE_SLEEP nunca coincidiu com a resposta de associação mesmo após longos períodos de teste usando os loops descritos abaixo (>12 horas).
No IW412, o atraso entre comandos que aciona um EVENT_SLEEP foi determinado empiricamente em ~20ms. Esse atraso pode ocorrer naturalmente quando o driver está emitindo informações de depuração (debug_mask = 0x00000037), situação na qual o problema das varreduras ocupadas é repetível ao executar "test 1)" conforme descrito abaixo. Se o atraso entre comandos for inferior a ~20ms, o firmware permanece acordado e o problema não foi reproduzido executando o mesmo teste.
O caminho host_mlme=false também se comporta diferentemente. Neste caso, toda a transação de autenticação/associação é executada por um único comando (HostCmd_CMD_802_11_ASSOCIATE), e o firmware não emite EVENT_SLEEP enquanto o comando está sendo executado.
Remova a atribuição para que ps_state seja manipulado apenas nos caminhos relacionados ao tratamento de eventos de powersave e na main workqueue para confirmação correta do sleep (suspensão).
Os seguintes testes com loops foram realizados (com saída de depuração habilitada): 1) Forçar roaming entre dois APs, um 5GHz e outro 2.4GHz, mesma SSID. Use wpa_cli para acionar o comportamento de roaming, aguarde 2 segundos entre as iterações. 2) Forçar uma desconexão do AP 1 e uma conexão ao AP 2, teste de varredura (scan). Use wpa_cli para acionar as alterações de conexão, aguarde 2 segundos entre as iterações.
Cada teste foi executado em cada dispositivo por pelo menos 3 horas.
If you want to get best quality of vulnerability data, you may have to visit VulDB.