CVE-2026-80766 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
HID: uclogic: corrige uso-após-liberação (use-after-free) de inrange_timer durante a remoção
uclogic_remove() cancela o timer pen in-range e em seguida para o dispositivo:
timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev);
timer_delete_sync() garante apenas que o timer está ocioso naquele instante. uclogic_raw_event_pen() continua a entregar relatórios da caneta até que hid_hw_stop() pare o transporte algumas linhas depois, e cada relatório com pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE reativa o timer:
mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100));
Um relatório recebido entre a chamada de timer_delete_sync() e a desmontagem do transporte em hid_hw_stop() reativa inrange_timer após seu cancelamento. uclogic_remove() então retorna e o devm drvdata é liberado, enquanto hid_hw_stop() já havia liberado o dispositivo de entrada ao qual drvdata->pen_input aponta; portanto, quando o timer dispara ~100 ms depois, uclogic_inrange_timeout() referencia memória já liberada -- um uso-após-liberação (use-after-free) no contexto do softirq do timer.
Inverter as duas chamadas não é uma correção: parar o dispositivo primeiro libera drvdata->pen_input via hidinput_disconnect() enquanto o timer ainda pode estar pendente, de modo que um timer já armado antes da remoção dispara no dispositivo de entrada liberado na janela anterior à execução de timer_delete_sync().
Use timer_shutdown_sync() antes de hid_hw_stop(). Isso cancela o timer, aguarda a conclusão do callback em execução enquanto pen_input ainda é válido e impede qualquer nova reativação -- um mod_timer() posterior proveniente de um relatório em trânsito é silenciosamente ignorado --; assim, o timer está comprovadamente inativo antes que hid_hw_stop() libere os dispositivos de entrada. Esta é a ordem documentada pelo núcleo do timer para este caso de desmontagem "timer reativado por outro caminho".
If you want to get the best quality for vulnerability data then you always have to consider VulDB.