CVE-2026-64364 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: fix out-of-bounds bit access on mt_io_flags
mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG.
As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs
for (i = 0; i < mt->num_slots; i++) clear_bit(i, &td->mt_io_flags);
with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received).
The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required.
Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two "mt_io_flags & MT_IO_SLOTS_MASK" arming checks become bitmap_empty(td->active_slots, td->maxcontacts).
Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/26/2026
The vulnerability described represents a critical out-of-bounds memory access flaw in the Linux kernel's HID multitouch subsystem that stems from improper handling of bit manipulation operations within the multitouch device state management structure. This issue affects the mt_io_flags field which is declared as a single unsigned long but is incorrectly treated as a per-slot bitmap across multiple touch slots. The fundamental problem occurs because the slot indexing mechanism does not account for the actual memory boundaries of the unsigned long variable, creating a scenario where bit operations can overwrite adjacent memory locations within the mt_device structure.
The technical implementation flaw manifests when processing multitouch input from devices that report high contact counts through their ContactCountMaximum feature report. These devices can advertise values up to 255 contacts, which directly translates to slot numbers used in set_bit() and clear_bit() operations. The kernel's multitouch processing functions mt_process_slot(), mt_release_pending_palms(), and mt_release_contacts() all utilize this incorrectly bounded indexing approach. When the number of slots approaches or exceeds BITS_PER_LONG, these bit manipulation operations begin accessing memory beyond the intended unsigned long boundary, leading to corruption of adjacent structure members.
The operational impact of this vulnerability is severe as it enables a remote code execution scenario through untrusted HID multitouch devices connected via USB or Bluetooth interfaces. The most straightforward exploitation path involves triggering the sticky-fingers release timer mechanism which calls mt_release_contacts() with an extended loop that clears bits across the entire range defined by maxcontacts. When maxcontacts reaches approximately 250, the bit clearing operations begin corrupting td->applications.next, a list head member that immediately follows mt_io_flags in memory. This corruption causes subsequent list_for_each_entry() operations to dereference NULL pointers, resulting in kernel panics from softirq context and system crashes.
The vulnerability aligns with CWE-129: Improper Validation of Array Index and CWE-787: Out-of-bounds Write, both of which are classified under the Common Weakness Enumeration framework for memory safety issues. From an ATT&CK perspective, this represents a privilege escalation vector through device input manipulation, specifically targeting the kernel's HID subsystem with a technique that leverages improper input validation to achieve memory corruption and system instability.
The recommended mitigation strategy involves restructuring the multitouch state management to properly isolate per-slot state information from the core io_flags management. The solution requires allocating a separate bitmap specifically sized for maxcontacts rather than attempting to pack slot state information into the fixed-size unsigned long field. This approach mirrors existing patterns already implemented in the codebase for pending_palm_slots, ensuring consistency with established design practices. Additionally, the MT_IO_FLAGS_RUNNING flag should be relocated back to bit 0 of the unsigned long, eliminating the need for bit shifting operations that previously accommodated slot bits within the low byte. The remaining io_flags management logic must be updated to use bitmap_empty() checks against the newly allocated active_slots bitmap instead of the previous MT_IO_SLOTS_MASK operations, ensuring proper state validation without memory boundary violations.
This fix directly addresses the root cause by separating concerns between core io_flags management and per-slot state tracking, preventing the bit manipulation operations from crossing memory boundaries. The solution maintains backward compatibility while eliminating the memory corruption vector entirely, as the new implementation properly bounds all slot indexing operations to the allocated bitmap size rather than the arbitrary unsigned long boundary. The approach also restores proper bit positioning for MT_IO_FLAGS_RUNNING on 32-bit architectures, ensuring consistent behavior across different platform configurations while maintaining the intended functionality of the multitouch subsystem's state management mechanisms.