CVE-2026-64364

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: multitouch: fix out-of-bounds bit access on mt_io_flags<br /> <br /> mt_io_flags is a single unsigned long, but mt_process_slot(),<br /> mt_release_pending_palms() and mt_release_contacts() use it as a<br /> per-slot bitmap indexed by the slot number. That slot number is only<br /> bounded by td-&gt;maxcontacts, which is taken from the device&amp;#39;s<br /> ContactCountMaximum feature report and can be up to 255, not by<br /> BITS_PER_LONG.<br /> <br /> As a result, a multitouch device that advertises a large contact count<br /> makes set_bit()/clear_bit() operate past the mt_io_flags word and<br /> corrupt the adjacent members of struct mt_device. The sticky-fingers<br /> release timer is the easiest way to reach this. mt_release_contacts()<br /> runs<br /> <br /> for (i = 0; i num_slots; i++)<br /> clear_bit(i, &amp;td-&gt;mt_io_flags);<br /> <br /> with num_slots == maxcontacts. For maxcontacts around 250 the loop<br /> clears the bits that overlap td-&gt;applications.next, zeroing that list<br /> head, and the list_for_each_entry() that immediately follows then<br /> dereferences NULL. The kernel panics from timer (softirq) context. On a<br /> KASAN build this shows up as a general protection fault in<br /> mt_release_contacts() with a null-ptr-deref at offset 0x58, which is<br /> offsetof(struct mt_application, num_received).<br /> <br /> The state is reachable from an untrusted USB or Bluetooth HID<br /> multitouch device; no local privileges are required.<br /> <br /> Store the per-slot active state in a separately allocated bitmap sized<br /> for maxcontacts, the same pattern already used for pending_palm_slots,<br /> and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two<br /> "mt_io_flags &amp; MT_IO_SLOTS_MASK" arming checks become<br /> bitmap_empty(td-&gt;active_slots, td-&gt;maxcontacts).<br /> <br /> Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the<br /> same commit to leave the low byte for the slot bits; with the slot bits<br /> gone it fits in bit 0 again, which also keeps it within the unsigned<br /> long on 32-bit.