CVE-2026-98859 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
HID: multitouch: impedire il riarmamento del timer di rilascio durante l'operazione di rimozione
mt_remove() mette in quiescenza il timer sticky-finger prima di arrestare l'hardware:
timer_delete_sync(&td->release_timer);
sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group); hid_hw_stop(hdev);
timer_delete_sync() attende che un callback in esecuzione termini e rimuove il timer dalla coda, ma non impedisce al timer di essere riarmato. Il transport continua a inviare report in quel momento e il percorso dei report lo riarma:
if (app->quirks & MT_QUIRK_STICKY_FINGERS) {
if (td->mt_io_flags & MT_IO_SLOTS_MASK) mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100));
Un report che arriva dopo il ritorno di timer_delete_sync() lascia quindi il timer accodato. td è allocato con devm_kzalloc() associato a hdev->dev, pertanto viene liberato quando il driver viene disassociato, dopo il ritorno da mt_remove(). Quando il timer scatta successivamente, mt_expired_timeout() dereferenzia il td già liberato:
struct mt_device *td = timer_container_of(td, t, release_timer); struct hid_device *hdev = td->hdev;
if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))
Spostare semplicemente la fase di teardown dopo hid_hw_stop() non risolve il problema da solo, poiché mt_expired_timeout() chiama mt_release_contacts(), che attraversa hdev->inputs; il timer deve comunque essere messo in quiescenza prima che hid_hw_stop() distrugga i dispositivi di input.
Utilizzare invece timer_shutdown_sync(), che rende inoltre qualsiasi successivo mod_timer() un'operazione nulla (no-op), così da non dover scegliere tra i due vincoli di ordinamento. Questo è lo schema di teardown finale per cui la funzione era stata introdotta, e hid-wiimote già lo utilizza per la stessa ragione.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.