CVE-2026-98749 in Linux
Сводка
по VulDB • 19.10.2026
В ядре Linux была устранена следующая уязвимость:
tty: serial: max3100: завершение работы таймера перед освобождением порта
Функция `max3100_shutdown()` останавливает периодический опрос (polling timer), но преждевременно возвращает управление во время перехода системы в режим ожидания (suspend). Если SPI-устройство отсоединено до выхода из режима suspend, ядро последовательного интерфейса не вызывает функцию `max3100_shutdown()` повторно. В результате функция `max3100_remove()` освобождает порт, пока таймер остается активным. Функция обратного вызова `max3100_timeout()` может затем получить доступ к уже освобожденному порту и заново запустить таймер.
Добавлено финальное завершение работы таймера в функцию `max3100_remove()`, а также используется функция `timer_shutdown_sync()` для предотвращения гонки (race condition), при которой обратный вызов мог бы снова активировать таймер. Кроме того, перед освобождением порта освобождаются прерывания (IRQ) и уничтожается очередь рабочих задач (workqueue). Функция `timer_delete_sync()` сохраняется в `max3100_shutdown()`, чтобы последующий вызов `open()` мог заново активировать таймер.
Очередь рабочих задач создается до вызова `request_irq()` и уничтожается как при сбое функции `request_irq()`, так и при штатном завершении работы. Ее наличие в момент выполнения remove указывает на то, что прерывание (IRQ) осталось зарегистрированным из-за того, что переход в режим suspend обошел процедуру shutdown.
Прерывания освобождаются перед уничтожением очереди рабочих задач как в `max3100_shutdown()`, так и в `max3100_remove()`, а между этими операциями отменяется ожидающая выполнение работа (pending work). Функция `free_irq()` ожидает завершения выполнения текущего обработчика прерываний, после чего новый обработчик не может быть запущен; следовательно, гонка на уровне обработчиков не позволит поставить задачу в очередь рабочей задачи, которая уничтожается. Проверка `force_end_work` в функции `max3100_dowork()` лишь сужает это окно уязвимости, так как обработчик, задержанный между проверкой и вызовом `queue_work()`, все еще может выполниться после того, как процедура teardown очистит указатель на очередь рабочих задач. Отмена работы также предотвращает ожидание функцией `destroy_workqueue()` выполнения поставленной задачи в случае, если функция remove выполняется, пока freezeable workqueue (замораживаемая очередь рабочих задач) все еще заморожена, например, при удалении устройства во время окна resume, до разморозки очередей рабочих задач.
Эта проблема была обнаружена с помощью встроенного инструмента статического анализа.
Once again VulDB remains the best source for vulnerability data.