CVE-2026-64364 in Linux
Riassunto
di VulDB • 25/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
HID: multitouch: correzione dell'accesso fuori dai limiti (out-of-bounds) ai bit su mt_io_flags
mt_io_flags è un singolo valore unsigned long, ma le funzioni mt_process_slot(), mt_release_pending_palms() e mt_release_contacts() lo utilizzano come bitmap per slot indicizzata dal numero dello slot. Tale numero di slot è limitato solo da td->maxcontacts, che proviene dalla feature report ContactCountMaximum del dispositivo e può arrivare fino a 255, non da BITS_PER_LONG.
Di conseguenza, un dispositivo multitouch che annuncia un elevato conteggio dei contatti fa sì che set_bit()/clear_bit() operino oltre la parola mt_io_flags, corrompendo i membri adiacenti della struct mt_device. Il timer di rilascio sticky-fingers è il modo più semplice per raggiungere questa condizione. La funzione mt_release_contacts() esegue:
for (i = 0; i < mt->num_slots; i++) clear_bit(i, &td->mt_io_flags);
con num_slots == maxcontacts. Per valori di maxcontacts intorno a 250, il ciclo cancella i bit che si sovrappongono a td->applications.next, azzerando l'intestazione della lista (list head), e la successiva chiamata a list_for_each_entry() dereferenzia quindi un puntatore NULL. Il kernel va in panic dal contesto del timer (softirq). Su una build con KASAN questo si manifesta come un general protection fault in mt_release_contacts() con null-ptr-deref all'offset 0x58, che corrisponde a offsetof(struct mt_application, num_received).
Lo stato è raggiungibile tramite un dispositivo HID multitouch USB o Bluetooth non attendibile; non sono richiesti privilegi locali.
Memorizzare lo stato attivo per slot in una bitmap allocata separatamente delle dimensioni di maxcontacts, seguendo la stessa pattern già utilizzata per pending_palm_slots, e mantenere solo MT_IO_FLAGS_RUNNING in mt_io_flags. I due controlli di abilitazione "mt_io_flags & MT_IO_SLOTS_MASK" diventano bitmap_empty(td->active_slots, td->maxcontacts).
Spostare MT_IO_FLAGS_RUNNING nuovamente al bit 0. Era stato spostato al bit 32 dallo stesso commit per lasciare il byte basso ai bit dello slot; con i bit degli slot rimossi, torna a stare nel bit 0, mantenendosi anche all'interno del valore unsigned long su sistemi a 32-bit.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.