CVE-2026-80766

Nel kernel Linux, la seguente vulnerabilità è stata risolta: HID: uclogic: correzione dello use-after-free di inrange_timer alla rimozione uclogic_remove() annulla il timer di pen in-range e poi arresta il dispositivo: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() garantisce solo che il timer sia inattivo in quell'istante. uclogic_raw_event_pen() continua a consegnare i report della penna finché hid_hw_stop() non arresta il trasporto diverse righe più sotto, e ogni report con pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE ri-arma il timer: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); Un report che arriva tra la chiamata a timer_delete_sync() e lo smantellamento del trasporto in hid_hw_stop() ri-arma inrange_timer dopo che era stato annullato. uclogic_remove() restituisce quindi il controllo e il drvdata devm viene liberato, mentre hid_hw_stop() ha già liberato il dispositivo di input a cui punta drvdata->pen_input, quindi quando il timer scatta ~100 ms dopo uclogic_inrange_timeout() dereferenzia memoria liberata -- uno use-after-free in contesto timer-softirq. Invertire le due chiamate non è una correzione: arrestare prima il dispositivo libera drvdata->pen_input tramite hidinput_disconnect() mentre il timer potrebbe essere ancora in sospeso, così un timer già armato prima della rimozione scatta sul dispositivo di input liberato nella finestra prima che venga eseguito timer_delete_sync(). Usare invece timer_shutdown_sync() prima di hid_hw_stop(). Annulla il timer, attende un callback in esecuzione mentre pen_input è ancora valido, e impedisce qualsiasi ulteriore riarmo -- un successivo mod_timer() da un report in-flight viene ignorato silenziosamente -- così il timer è dimostrabilmente disattivato prima che hid_hw_stop() liberi gli input. Questo è l'ordinamento che il timer core documenta per questo caso di teardown "timer ri-armato da un altro percorso".