CVE-2026-64364

What it actually does

This is a Linux kernel memory corruption flaw in the HID multitouch driver. The driver stores per-touch-slot state in a single unsigned long, but indexes it using a slot number derived from an untrusted HID multitouch device's advertised ContactCountMaximum value, which can be much larger than the number of bits in an unsigned long. A malicious USB or Bluetooth HID multitouch device can therefore cause set_bit() or clear_bit() operations to write past mt_io_flags and corrupt adjacent fields in the kernel's mt_device structure. The most straightforward observed outcome is a kernel panic from timer/softirq context when corrupted list pointers are later dereferenced, but because this is kernel memory corruption reachable without local privileges, the theoretical impact includes loss of availability and potentially broader compromise of kernel integrity/confidentiality depending on architecture, hardening, and exploitability.

Why it matters to the business

Systems that accept untrusted USB or Bluetooth HID devices can be crashed by a malicious or compromised multitouch peripheral, causing workstation, kiosk, embedded, point-of-sale, industrial control, or shared-use Linux systems to become unavailable until rebooted. The issue is not known to be exploited in the wild, is not in CISA KEV, has low current EPSS, and has no reported public exploit maturity, so urgency is highest for environments where physical access, Bluetooth pairing, peripheral sharing, supply-chain peripheral risk, or public-facing kiosks are realistic concerns.

How an attack unfolds

An attacker needs adjacent/physical proximity rather than network access. They present a malicious USB or Bluetooth HID multitouch device to a vulnerable Linux system. During HID feature/report parsing, the device advertises an excessive ContactCountMaximum, such as a value near 250. The kernel multitouch driver accepts that value as the number of slots. When the sticky-fingers release timer or related contact-release logic runs, the driver iterates across the advertised slot count and clears bits in mt_io_flags as though it were a large bitmap. Because mt_io_flags is only one unsigned long, those operations run out of bounds and overwrite neighboring struct members. In the demonstrated path, this corrupts the applications list head, and subsequent list traversal dereferences a null or invalid pointer, causing a kernel general protection fault or panic. A more advanced attacker would attempt to shape the corrupted data and timing to move beyond denial of service, though exploitation beyond crash is not currently indicated by the provided data.

How to fix it

Apply the vendor kernel update that includes the HID multitouch fix changing per-slot active state from mt_io_flags to a separately allocated bitmap sized to maxcontacts, and keeping only the running flag in mt_io_flags. No exact package fixed versions were provided, so use distribution advisories and kernel changelogs to identify the first fixed kernel for each platform. Where immediate patching is not possible, reduce exposure by blocking untrusted USB HID devices, disabling or restricting Bluetooth pairing, enforcing USB device control/allowlisting, disabling unused HID multitouch support where operationally acceptable, and avoiding attachment of unknown touchscreens, touchpads, digitizers, or composite HID devices. For high-risk public or shared systems, combine patching with physical port controls and Bluetooth policy enforcement.

How to confirm the fix worked

Confirm that the running kernel version is at or above the distribution's fixed release for this issue, not merely that a patched package is installed but pending reboot. Validate through vendor advisory mapping, package changelog entries referencing the HID multitouch mt_io_flags out-of-bounds fix, or source-level confirmation that active slot state is stored in an allocated bitmap such as active_slots and arming checks use bitmap_empty() rather than treating mt_io_flags as a per-slot bitmap. Confirm whether hid-multitouch is loaded or available on exposed systems. After remediation, reboot into the fixed kernel and verify with uname/package inventory. Where safe test infrastructure exists, attach only controlled HID test hardware or fuzzing rigs to confirm that large ContactCountMaximum values no longer trigger kernel warnings or crashes; do not run such tests on production systems.

Typical attack path

1. Obtain physical proximity to the target system or an opportunity to pair/connect a malicious Bluetooth HID device.
2. Emulate or modify a USB/Bluetooth HID multitouch device so it advertises an abnormally large ContactCountMaximum value.
3. Connect or pair the device with a vulnerable Linux system that loads the hid-multitouch driver.
4. Trigger multitouch contact activity or release behavior so mt_process_slot(), mt_release_pending_palms(), or mt_release_contacts() processes slot indexes beyond the size of mt_io_flags.
5. Cause out-of-bounds bit operations that corrupt adjacent kernel structure fields.
6. Trigger follow-on list traversal or timer/softirq execution that dereferences corrupted pointers, commonly resulting in a kernel panic and system outage.

How to detect it

Look for evidence of kernel crashes or warnings occurring shortly after USB or Bluetooth HID device enumeration, especially multitouch devices reporting unusually high contact counts. Primary log sources are kernel ring buffer output, persistent journal logs, syslog/kern.log/messages, crash dump systems such as kdump/vmcore, endpoint telemetry for USB/Bluetooth device connection events, and hardware inventory records. Search for stack traces naming hid-multitouch functions such as mt_release_contacts(), mt_release_pending_palms(), or mt_process_slot(), general protection faults, null pointer dereferences, KASAN reports, or softirq/timer-context panics. Correlate these with recent connection/pairing of HID multitouch, touchscreen, touchpad, digitizer, or composite USB/Bluetooth devices. If crash dumps are available, inspect the call trace for the HID multitouch release path and look for corrupted list pointers or faults near struct mt_application fields. Because exploitation may only produce a crash and not durable files or network traffic, absence of persistent IOCs does not prove absence of attempted exploitation.

• mt_release_contacts
• mt_release_pending_palms
• mt_process_slot
• hid-multitouch
• hid_multitouch
• ContactCountMaximum
• general protection fault
• NULL pointer dereference
• KASAN:
• BUG: KASAN
• RIP: 0010:mt_release_contacts
• Call Trace:
• softirq
• kernel panic
• Bluetooth HID
• USB HID
• multitouch
• HID: multitouch

What your security team should do

• Prioritize patching Linux systems that allow physical peripheral access, Bluetooth HID pairing, public kiosk use, lab equipment access, or third-party device attachment.
• Inventory systems with hid-multitouch capability or loaded hid_multitouch modules and map them to vendor-fixed kernel versions.
• Enforce USB and Bluetooth device-control policies, including allowlisting trusted HID devices and disabling unused Bluetooth pairing on sensitive endpoints.
• Review kernel crash logs and endpoint telemetry for recent panics involving hid-multitouch, mt_release_contacts, mt_process_slot, or KASAN/general protection faults after HID device connection events.
• For public/shared systems, add physical port protection and operational procedures to treat unknown touchscreens, touchpads, and composite HID devices as untrusted.
• Track distribution advisories because fixed package versions are platform-specific and were not provided in the input.
• Do not treat the low EPSS and absence from KEV as a reason to ignore the issue on physically accessible Linux assets; exposure is driven by local/adjacent device access rather than internet reachability.