<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 03:40:41 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-64364 — HID: multitouch: fix out-of-bounds bit access on mt_io_flags</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-64364</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;HID: multitouch: fix out-of-bounds bit access on mt_io_flags&lt;/p&gt;
&lt;p&gt;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-&amp;gt;maxcontacts, which is taken from the device&amp;#39;s
ContactCountMaximum feature report and can be up to 255, not by
BITS_PER_LONG.&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; mt-&amp;gt;num_slots; i++)
		clear_bit(i, &amp;amp;td-&amp;gt;mt_io_flags);&lt;/p&gt;
&lt;p&gt;with num_slots == maxcontacts. For maxcontacts around 250 the loop
clears the bits that overlap td-&amp;gt;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).&lt;/p&gt;
&lt;p&gt;The state is reachable from an untrusted USB or Bluetooth HID
multitouch device; no local privileges are required.&lt;/p&gt;
&lt;p&gt;Store the per-slot active state in a separately allocated bitmap sized
for maxcontacts, the same pattern alrea…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;HID: multitouch: fix out-of-bounds bit access on mt_io_flags&lt;/p&gt;
&lt;p&gt;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-&amp;gt;maxcontacts, which is taken from the device&amp;#39;s
ContactCountMaximum feature report and can be up to 255, not by
BITS_PER_LONG.&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; mt-&amp;gt;num_slots; i++)
		clear_bit(i, &amp;amp;td-&amp;gt;mt_io_flags);&lt;/p&gt;
&lt;p&gt;with num_slots == maxcontacts. For maxcontacts around 250 the loop
clears the bits that overlap td-&amp;gt;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).&lt;/p&gt;
&lt;p&gt;The state is reachable from an untrusted USB or Bluetooth HID
multitouch device; no local privileges are required.&lt;/p&gt;
&lt;p&gt;Store the per-slot active state in a separately allocated bitmap sized
for maxcontacts, the same pattern alrea…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-64364</guid>
    </item>
  </channel>
</rss>
