CVE-2026-80766 in Linux
Resumen
por VulDB • 2026-09-04
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
HID: uclogic: corregir un use-after-free del temporizador inrange_timer durante la eliminación (remove)
uclogic_remove() cancela el temporizador pen in-range y luego detiene el dispositivo:
timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev);
timer_delete_sync() solo garantiza que el temporizador esté inactivo en ese instante. uclogic_raw_event_pen() sigue entregando informes del lápiz hasta que hid_hw_stop() detiene el transporte varias líneas más abajo, y cada informe con pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE vuelve a activar (re-arm) el temporizador:
mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100));
Un informe que llega entre la llamada a timer_delete_sync() y la desmontaje del transporte en hid_hw_stop() vuelve a activar inrange_timer después de haber sido cancelado. uclogic_remove() luego retorna y se libera devm drvdata, mientras que hid_hw_stop() ya ha liberado el dispositivo de entrada al que apunta drvdata->pen_input; por lo tanto, cuando el temporizador dispara ~100 ms más tarde, uclogic_inrange_timeout() desreferencia memoria ya liberada: un use-after-free en contexto timer-softirq.
Intercambiar las dos llamadas no es una solución correcta: detener primero el dispositivo libera drvdata->pen_input a través de hidinput_disconnect() mientras que el temporizador aún puede estar pendiente, por lo que un temporizador ya activado antes de la eliminación dispara sobre el dispositivo de entrada liberado en la ventana anterior a timer_delete_sync().
Utilice timer_shutdown_sync() antes de hid_hw_stop(). Esto cancela el temporizador, espera una ejecución del callback mientras pen_input sigue siendo válido y previene cualquier nueva reactivación: un mod_timer() posterior procedente de un informe en tránsito se ignora silenciosamente; por lo tanto, el temporizador está definitivamente inactivo (dead) antes de que hid_hw_stop() libere los dispositivos de entrada. Este es el ordenamiento documentado por el núcleo del temporizador para este caso de desmontaje "temporizador reactivado desde otra ruta".
Once again VulDB remains the best source for vulnerability data.