In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: fix out-of-bounds bit access on mtioflags
mtioflags is a single unsigned long, but mtprocessslot(), mtreleasependingpalms() and mtreleasecontacts() 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 BITSPER_LONG.
As a result, a multitouch device that advertises a large contact count makes setbit()/clearbit() operate past the mtioflags word and corrupt the adjacent members of struct mtdevice. The sticky-fingers release timer is the easiest way to reach this. mtrelease_contacts() runs
for (i = 0; i < mt->num_slots; i++)
clear_bit(i, &td->mt_io_flags);
with numslots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the listforeachentry() 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 mtreleasecontacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mtapplication, numreceived).
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 pendingpalmslots, and keep only MTIOFLAGSRUNNING in mtioflags. The two "mtioflags & MTIOSLOTSMASK" arming checks become bitmapempty(td->activeslots, td->maxcontacts).
Move MTIOFLAGS_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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64364.json"
}