CVE-2026-80766 in Linux
Сводка
по VulDB • 04.09.2026
В ядре Linux устранена следующая уязвимость:
HID: uclogic: исправлена ошибка use-after-free (использование после освобождения) таймера inrange_timer при удалении устройства
Функция `uclogic_remove()` отменяет таймер обнаружения пера в рабочей зоне и затем останавливает устройство:
```c timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); ```
`timer_delete_sync()` гарантирует лишь то, что таймер находится в состоянии простоя на данный момент. Функция `uclogic_raw_event_pen()` продолжает передавать отчеты о перо до тех пор, пока `hid_hw_stop()`, расположенный несколькими строками ниже, не остановит транспортный слой. Каждый отчет с параметром `pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE` повторно активирует таймер:
```c mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); ```
Отчет, поступивший между вызовом `timer_delete_sync()` и процессом разбора транспортного слоя в `hid_hw_stop()`, повторно активирует `inrange_timer` после его отмены. Затем функция `uclogic_remove()` возвращает управление, а структура данных устройства (`devm drvdata`) освобождается. При этом `hid_hw_stop()` уже освободил устройство ввода, на которое указывает `drvdata->pen_input`. Следовательно, когда таймер срабатывает примерно через 100 мс, функция `uclogic_inrange_timeout()` обращается к освобожденной памяти — возникает ошибка use-after-free в контексте softirq таймера.
Простая замена порядка вызовов не является решением: остановка устройства сначала приводит к освобождению `drvdata->pen_input` через `hidinput_disconnect()`, пока таймер может все еще находиться в состоянии ожидания (pending). В результате уже активированный перед удалением таймер срабатывает для освобожденного устройства ввода в окне времени до выполнения `timer_delete_sync()`.
Вместо этого следует использовать `timer_shutdown_sync()` перед вызовом `hid_hw_stop()`. Эта функция отменяет таймер, ожидает завершения выполняющегося обратного вызова (callback), пока структура `pen_input` все еще действительна, и предотвращает любую дальнейшую повторную активацию — последующий вызов `mod_timer()` из обрабатываемого в данный момент отчета игнорируется молча. Таким образом, таймер гарантированно перестает функционировать до того, как `hid_hw_stop()` освободит ресурсы ввода. Это соответствует порядку действий (ordering), описанному ядром таймеров для случая разбора системы («таймер повторно активирован из другого пути»).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.