CVE-2026-80766

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: uclogic: Use-after-free von inrange_timer beim Entfernen beheben uclogic_remove() bricht den Pen-In-Range-Timer ab und stoppt dann das Gerät: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() garantiert nur, dass der Timer in diesem Moment inaktiv ist. uclogic_raw_event_pen() liefert weiterhin Pen-Reports, bis hid_hw_stop() den Transport einige Zeilen später stoppt, und jeder Report mit pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE startet den Timer neu: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); Ein Report, der zwischen dem timer_delete_sync()-Aufruf und dem Transport-Teardown in hid_hw_stop() ankommt, startet den inrange_timer neu, nachdem er abgebrochen wurde. uclogic_remove() kehrt dann zurück und die devm drvdata wird freigegeben, während hid_hw_stop() das Eingabegerät, auf das drvdata->pen_input zeigt, bereits freigegeben hat. Wenn der Timer also ~100 ms später feuert, dereferenziert uclogic_inrange_timeout() freigegebenen Speicher -- ein Use-after-free im Timer-Softirq-Kontext. Das Vertauschen der beiden Aufrufe ist keine Lösung: Das vorherige Stoppen des Geräts gibt drvdata->pen_input über hidinput_disconnect() frei, während der Timer noch ausstehen könnte. Ein vor dem Entfernen bereits aktivierter Timer feuert also auf dem freigegebenen Eingabegerät in dem Zeitfenster, bevor timer_delete_sync() ausgeführt wird. Verwenden Sie stattdessen timer_shutdown_sync() vor hid_hw_stop(). Es bricht den Timer ab, wartet auf einen laufenden Callback, während pen_input noch gültig ist, und verhindert ein erneutes Aktivieren -- ein späteres mod_timer() aus einem in-flight Report wird stillschweigend ignoriert --, sodass der Timer nachweislich tot ist, bevor hid_hw_stop() die Eingaben freigibt. Dies ist die Reihenfolge, die der Timer-Core für diesen Teardown-Fall „Timer von einem anderen Pfad aus neu aktiviert“ dokumentiert.