GHSA-9VQ4-GG6C-67HR
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-25 12:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-64364"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:19Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: fix out-of-bounds bit access on mt_io_flags\n\nmt_io_flags is a single unsigned long, but mt_process_slot(),\nmt_release_pending_palms() and mt_release_contacts() use it as a\nper-slot bitmap indexed by the slot number. That slot number is only\nbounded by td-\u003emaxcontacts, which is taken from the device\u0027s\nContactCountMaximum feature report and can be up to 255, not by\nBITS_PER_LONG.\n\nAs a result, a multitouch device that advertises a large contact count\nmakes set_bit()/clear_bit() operate past the mt_io_flags word and\ncorrupt the adjacent members of struct mt_device. The sticky-fingers\nrelease timer is the easiest way to reach this. mt_release_contacts()\nruns\n\n\tfor (i = 0; i \u003c mt-\u003enum_slots; i++)\n\t\tclear_bit(i, \u0026td-\u003emt_io_flags);\n\nwith num_slots == maxcontacts. For maxcontacts around 250 the loop\nclears the bits that overlap td-\u003eapplications.next, zeroing that list\nhead, and the list_for_each_entry() that immediately follows then\ndereferences NULL. The kernel panics from timer (softirq) context. On a\nKASAN build this shows up as a general protection fault in\nmt_release_contacts() with a null-ptr-deref at offset 0x58, which is\noffsetof(struct mt_application, num_received).\n\nThe state is reachable from an untrusted USB or Bluetooth HID\nmultitouch device; no local privileges are required.\n\nStore the per-slot active state in a separately allocated bitmap sized\nfor maxcontacts, the same pattern already used for pending_palm_slots,\nand keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two\n\"mt_io_flags \u0026 MT_IO_SLOTS_MASK\" arming checks become\nbitmap_empty(td-\u003eactive_slots, td-\u003emaxcontacts).\n\nMove MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the\nsame commit to leave the low byte for the slot bits; with the slot bits\ngone it fits in bit 0 again, which also keeps it within the unsigned\nlong on 32-bit.",
"id": "GHSA-9vq4-gg6c-67hr",
"modified": "2026-07-25T12:31:33Z",
"published": "2026-07-25T12:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64364"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12e90656e330ff8bbaf2f29c535fdb8a11cc6f55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/152983d87387f6a8ae72b73474cfa55fbcf1ec75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37daa8c96bd563d03150e23f094cb60703594a6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6493ebf9489efef0105078377b973ab33d51af22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8813b0612275cc61fe9e6603d0ee019247ade6be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a6d5ce2e1a2d7bf189bde8a659d04b65f0b0725d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5c037d6b807017e74a115288f81bc9cd5a5aab8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e24918ee67c4dc3d20d4670750e46e9b160365f4"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.