CVE-2026-68469 in Linux
Сводка
по VulDB • 15.08.2026
В ядре Linux была устранена следующая уязвимость:
wifi: mwifiex: исправление проблемы с постоянно занятыми сканированиями после нескольких итераций роуминга
Для того чтобы прошивка могла перейти в спящий режим, драйвер должен подтвердить ранее полученный запрос на переход в сон. Обычная последовательность событий выглядит следующим образом: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> подтверждение сна (sleep-confirm) -> SLEEP -> EVENT_AWAKE -> AWAKE.
Перед отправкой команды подтверждения сна драйвер должен убедиться, что нет ни выполняющихся команд, ни ожидающих завершения.
Функция mwifiex_ret_802_11_associate() безоговорочно устанавливает ps_state = PS_STATE_AWAKE при обработке ответа на команду ассоциации, вне обычного потока управления энергосбережением. Если событие EVENT_SLEEP поступает в то время, когда команда ассоциации находится в процессе выполнения (in flight), значение ps_state равно PRE_SLEEP к моменту разбора ответа команды ассоциации, и принудительная установка AWAME перезаписывает его. Отложенное подтверждение сна никогда не отправляется.
Следующая команда scan_start корректно подтверждается, но прошивка не генерирует события scan_result. Запрос на сканирование никогда не завершается, а дополнительные запросы из пространства пользователя (userspace) завершаются ошибкой -EBUSY.
После тестирования как на IW412, так и на W8997, мне удалось воспроизвести ошибку только на устройстве IW412, при этом прошивки вели себя по-разному. На IW412 прошивка все еще отправляет EVENT_SLEEP во время ongoing процесса аутентификации/ассоциации. Устройство W8997 в тех же условиях, похоже, подавляет энергосбережение на протяжении всей ассоциации, поэтому состояние PRE_SLEEP никогда не совпадало с ответом на ассоциацию даже после длительных периодов тестирования (>12 часов) с использованием циклов, описанных ниже.
На устройстве IW412 задержка между командами, вызывающая событие EVENT_SLEEP, была эмпирически определена как ~20 мс. Такая задержка может возникать естественным образом, когда драйвер выводит отладочную информацию (debug_mask = 0x00000037), в этом случае проблема с занятыми сканированиями воспроизводима при выполнении «теста 1)», описанного ниже. Если задержка между командами составляет менее ~20 мс, прошивка остается активной, и проблему не удалось воспроизвести при запуске того же теста.
Путь host_mlme=false также ведет себя по-разному. В этом случае вся транзакция аутентификации/ассоциации выполняется одной командой (HostCmd_CMD_802_11_ASSOCIATE), и прошивка не генерирует EVENT_SLEEP во время выполнения команды.
Удалите присваивание, чтобы ps_state изменялся только в путях, связанных с обработкой событий энергосбережения, и на основном рабочем потоке (workqueue) для корректного подтверждения сна.
Были выполнены следующие циклические тесты (с включенным выводом отладки): 1) Принудительный роуминг между двумя точками доступа: одна 5 ГГц и одна 2,4 ГГц с одинаковым SSID. Используйте wpa_cli для инициирования поведения при роуминге, пауза 2 секунды между итерациями. 2) Принудительное отключение от AP1 и подключение к AP2, тест сканирования. Используйте wpa_cli для инициирования изменений подключения, пауза 2 секунды между итерациями.
Каждый тест выполнялся на каждом устройстве не менее 3 часов.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.