Zum Inhalt springen
← Zurück zum Cyberlagebild
Zuletzt aktualisiert 11.09.2026 02:54

CVE-2026-64364

CVSS 8.81 Quelle

Beschreibung

Im Linux-Kernel wurde die folgende Sicherheitsanfälligkeit behoben: HID: multitouch: fix out-of-bounds bit access on mt io flags mt io flags ist ein einzelnes unsigniertes long, aber mt process slot(), mt release pending palms() und mt release contacts() verwenden es als per-slot-Bitmap, die durch die Slotnummer indiziert wird. Diese Slotnummer wird nur durch td->maxcontacts begrenzt, die aus dem Funktionsbericht des Geräts ContactCountMaximum entnommen wird und bis zu 255 betragen kann, nicht durch BITS PER LONG. Infolgedessen lässt ein Multitouch-Gerät, das eine große Kontaktzahl ankündigt, set bit()/clear bit() am mt io flags-Wort vorbei arbeiten und die benachbarten Mitglieder des struct mt device korrumpieren. Der klebrige Finger Release Timer ist der einfachste Weg, dies zu erreichen. mt release contacts() läuft für (i = 0; i < mt->num slots; i++) clear bit(i, &td->mt io flags); mit num slots == maxcontacts. Für maxcontacts um 250 löscht die Schleife die Bits, die sich überlappen td->applications.next, Nullierung dieser Liste Kopf, und die list for each entry(), die unmittelbar folgt dann dereferences NULL. Der Kernel gerät in Panik aus dem Timer-Kontext (Softirq). Auf einem KASAN-Build wird dies als allgemeiner Schutzfehler in mt release contacts() mit einem null-ptr-deref am Offset 0x58 angezeigt, der offsetof(struct mt application, num received) ist. Der Zustand ist von einem nicht vertrauenswürdigen USB- oder Bluetooth-HID-Multitouch-Gerät aus erreichbar; es sind keine lokalen Privilegien erforderlich. Speichern Sie den pro-Slot aktiven Zustand in einer separat zugewiesenen Bitmap in der Größe von maxcontacts, dem gleichen Muster, das bereits für pending palm slots verwendet wurde, und halten Sie nur MT IO FLAGS RUNNING in mt io flags. Die beiden Arming-Checks "mt io flags & MT IO SLOTS MASK" werden zu bitmap empty(td->active slots, td->maxcontacts). Bewegen Sie MT IO FLAGS RUNNING zurück zu Bit 0. Es wurde mit dem gleichen Commit auf Bit 32 gestoßen, um das niedrige Byte für die Slot-Bits zu verlassen; Mit den Slot-Bits passt es wieder in Bit 0, was es auch innerhalb des unsignierten Long auf 32-Bit hält.

Herstellerlinux
Produktlinux kernel
ProduktfamilieKeine Angaben
Betroffene Versionen>=5.10.246 <5.10.261, >=5.15.196 <5.15.212, >=6.1.158 <6.1.178, >=6.6.114 <6.6.145, >=6.12.55 <6.12.97, >=6.17.5 <6.18, >=6.18.1 <6.18.39, >=6.19 <7.1.4, 6.18, 7.2
Behobene VersionenKeine Angaben

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

PrioritätGelb
EinordnungZeitnah behandeln: hohes technisches Risiko.

Empfohlene Schritte

  • Betroffene Systeme identifizieren: linux linux kernel.
  • Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
  • Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
  • Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

  • Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
  • WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
  • Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.