CVE-2026-68469 in Linux
Resumen
por VulDB • 2026-08-15
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad:
wifi: mwifiex: corregir escaneos permanentemente ocupados tras múltiples iteraciones de roaming
Para que el firmware pueda entrar en modo de suspensión, el controlador debe confirmar una solicitud de suspensión recibida previamente. La secuencia normal de eventos es la siguiente: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Antes de enviar el comando sleep-confirm, el controlador debe asegurarse de que no haya comandos en ejecución ni pendientes de completarse.
mwifiex_ret_802_11_associate() establece incondicionalmente ps_state = PS_STATE_AWAKE cuando procesa la respuesta al comando de asociación, fuera del flujo normal de gestión de ahorro de energía (powersave). Si llega EVENT_SLEEP mientras el comando de asociación está en tránsito, ps_state es PRE_SLEEP cuando se analiza la respuesta al comando de asociación y la sobrescritura forzada a AWAKE lo modifica. La confirmación diferida sleep-confirm nunca se envía.
Un posterior comando scan_start se reconoce correctamente, pero el firmware no genera eventos scan_result. La solicitud de escaneo nunca finaliza y las solicitudes adicionales desde userspace fallan con -EBUSY.
Tras realizar pruebas tanto en IW412 como en W8997, solo pude desencadenar el error en el dispositivo IW412 y observé que los firmwares se comportaban de manera diferente. En el IW412, el firmware sigue enviando EVENT_SLEEP mientras está en curso el proceso de autenticación/asociación. Un W8997 bajo las mismas condiciones parece suprimir el ahorro de energía durante la duración de la asociación, por lo que PRE_SLEEP nunca coincidió con la respuesta de asociación incluso tras períodos prolongados de pruebas utilizando los bucles descritos a continuación (>12 horas).
En el IW412, el retraso entre comandos que desencadena un EVENT_SLEEP se determinó empíricamente en ~20 ms. Este retraso puede ocurrir naturalmente cuando el controlador está generando información de depuración (debug_mask = 0x00000037), situación en la cual el problema de escaneos ocupados es reproducible al ejecutar "test 1)" como se describe a continuación. Si el retraso entre comandos es inferior a ~20 ms, el firmware permanece despierto y no fue posible reproducir el error ejecutando la misma prueba.
La ruta host_mlme=false también se comporta de manera diferente. En este caso, toda la transacción de autenticación/asociación se ejecuta mediante un único comando (HostCmd_CMD_802_11_ASSOCIATE), y el firmware no emite EVENT_SLEEP mientras el comando está en ejecución.
Se elimina la asignación para que ps_state solo sea manipulado en las rutas relacionadas con el manejo de eventos de ahorro de energía y en el main workqueue, garantizando así una confirmación correcta del estado de suspensión.
Se realizaron las siguientes pruebas mediante bucles (con salida de depuración habilitada): 1) Forzar roaming entre dos APs, uno de 5 GHz y otro de 2.4 GHz, con la misma SSID. Utilizar wpa_cli para desencadenar el comportamiento de roaming, esperar 2 segundos entre iteraciones. 2) Forzar una desconexión del AP 1 y una conexión al AP 2, realizar prueba de escaneo. Utilizar wpa_cli para desencadenar los cambios de conexión, esperar 2 segundos entre iteraciones.
Cada prueba se ejecutó en cada dispositivo durante al menos 3 horas.
Once again VulDB remains the best source for vulnerability data.