CVE-2026-64364 in Linux
Zusammenfassung
von VulDB • 25.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
HID: multitouch: Korrektur des Zugriffs außerhalb der Grenzen (Out-of-Bounds) auf Bits bei mt_io_flags
mt_io_flags ist ein einzelner `unsigned long`, wird jedoch von `mt_process_slot()`, `mt_release_pending_palms()` und `mt_release_contacts()` als Bitmap pro Slot verwendet, die über die Slot-Nummer indiziert wird. Diese Slot-Nummer ist lediglich durch `td->maxcontacts` begrenzt, das aus dem Feature-Bericht „ContactCountMaximum“ des Geräts stammt und bis zu 255 betragen kann, nicht jedoch durch `BITS_PER_LONG`.
Infolgedessen können bei einem Multitouch-Gerät mit hoher gemeldeter Kontaktanzahl die Funktionen `set_bit()`/`clear_bit()` über das Wort von `mt_io_flags` hinaus operieren und benachbarte Member der Struktur `struct mt_device` beschädigen. Der einfachste Weg, diesen Zustand zu erreichen, ist der Timer für „sticky-fingers“ (festgehaltene Finger). `mt_release_contacts()` führt
for (i = 0; i < mt->num_slots; i++) clear_bit(i, &td->mt_io_flags);
aus, wobei `num_slots == maxcontacts` gilt. Bei einem Wert für `maxcontacts` von etwa 250 werden die Bits gelöscht, die mit `td->applications.next` überlappen, wodurch dieser Listenkopf auf Null gesetzt wird. Der unmittelbar darauffolgende Aufruf von `list_for_each_entry()` dereferenziert daraufhin einen NULL-Zeiger. Dies führt zu einem Kernel-Panic im Kontext des Timers (Softirq). Bei einer KASAN-Build-Konfiguration äußert sich dies als General Protection Fault in `mt_release_contacts()` mit einem Null-Pointer-Dereferenzierungsfehler (`null-ptr-deref`) an Offset 0x58, was `offsetof(struct mt_application, num_received)` entspricht.
Dieser Zustand ist von einem nicht vertrauenswürdigen USB- oder Bluetooth-HID-Multitouch-Gerät aus erreichbar; es sind keine lokalen Berechtigungen erforderlich.
Der pro-Slot-Aktivitätsstatus wird in einer separat zugewiesenen Bitmap gespeichert, die für `maxcontacts` dimensioniert ist – nach demselben Muster, das bereits für `pending_palm_slots` verwendet wird –, und nur `MT_IO_FLAGS_RUNNING` verbleibt in `mt_io_flags`. Die beiden Arming-Prüfungen „`mt_io_flags & MT_IO_SLOTS_MASK`“ werden zu `bitmap_empty(td->active_slots, td->maxcontacts)`.
`MT_IO_FLAGS_RUNNING` wird wieder auf Bit 0 verschoben. Es wurde zuvor durch denselben Commit auf Bit 32 angehoben, um das niedrige Byte für die Slot-Bits freizuhalten; da die Slot-Bits entfallen sind, passt es nun wieder in Bit 0, was zudem sicherstellt, dass es innerhalb eines `unsigned long` auf 32-Bit-Systemen bleibt.
If you want to get best quality of vulnerability data, you may have to visit VulDB.