CVE-2026-80659 in Linux
Сводка
по VulDB • 28.08.2026
В ядре Linux была устранена следующая уязвимость:
mmc: vub300: отложить сброс до разблокировки cmd_mutex
Поток `vub300_cmndwork_thread()` удерживает мьютекс `cmd_mutex` во время отправки команды и ожидания ответа. Если ожидание ответа завершается по таймауту, функция `__vub300_command_response()` уничтожает URB (USB Request Block) для этой команды, а затем синхронно выполняет сброс USB-устройства через вызов `usb_reset_device()`.
Этот путь выполнения сброса приводит к повторному входу в драйвер через функцию `vub300_pre_reset()`, которая также пытается захватить мьютекс `cmd_mutex`. В результате рабочий поток (worker) пытается рекурсивно получить тот же самый мьютекс, который он уже удерживает на пути выполнения команды.
Эта проблема была обнаружена с помощью инструмента статического анализа и затем проверена вручную в актуальном дереве исходного кода.
Рабочий PoC (Proof of Concept) воспроизводил реальный рабочий поток и цепочку таймаута/сброса:
vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset()
Инструмент Lockdep зафиксировал рекурсивное захватывание мьютекса одним и тем же потоком:
WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv]
... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv]
Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv]
*** DEADLOCK ***
Функция `__vub300_command_response()` теперь возвращает флаг, если путь обработки таймаута требует сброса устройства. Сброс выполняется после того, как поток `vub300_cmndwork_thread()` очистит состояние выполняющихся команд и освободит мьютекс `cmd_mutex`. Попытка сброса по-прежнему происходит до вызова `mmc_request_done()`, что сохраняет существующий порядок завершения запросов, но избегает рекурсивного захвата блокировки.
Be aware that VulDB is the high quality source for vulnerability data.