Linux Input/HID development
 help / color / mirror / Atom feed
From: Your Name <qwe.aldo@gmail.com>
To: linux-input@vger.kernel.org
Cc: jikos@kernel.org, bentiss@kernel.org,
	linux-kernel@vger.kernel.org,
	Aldo Ariel Panzardo <qwe.aldo@gmail.com>,
	stable@vger.kernel.org
Subject: [PATCH] HID: multitouch: bound the slot index before touching mt_io_flags
Date: Thu, 23 Jul 2026 19:42:11 -0300	[thread overview]
Message-ID: <20260723224211.613112-1-you@example.com> (raw)

From: Aldo Ariel Panzardo <qwe.aldo@gmail.com>

td->mt_io_flags is a single unsigned long.  Its first MT_IO_SLOTS_BITS
bits track per-slot state, read back through MT_IO_SLOTS_MASK, while bit
32 holds MT_IO_FLAGS_RUNNING, which the report path and the sticky-finger
timer take and release with test_and_set_bit_lock() and
clear_bit_unlock().

set_bit()/clear_bit() are called on that word with the slot number as the
bit index:

	set_bit(slotnum, &td->mt_io_flags);

slotnum is bounded only by td->maxcontacts, which is taken from the HID
CONTACTMAX feature value and can reach MT_MAX_MAXCONTACT (250).  Two
things go wrong once a device reports a slot number of 8 or more:

 - a slot number of 32 sets MT_IO_FLAGS_RUNNING from the data path.
   mt_expired_timeout() then finds the flag already set and returns
   early, so sticky fingers are never released, and the
   clear_bit_unlock() in the other path drops a lock it does not hold.
   Several in-tree classes declare .maxcontacts of 40 and 60, so this is
   reachable with ordinary hardware.

 - a slot number of BITS_PER_LONG or more writes past the end of the word
   altogether, corrupting the struct mt_device fields that follow it.

The same unchecked index is used in mt_release_pending_palms(), where
slotnum comes from a for_each_set_bit() bounded by td->maxcontacts, and
in mt_release_contacts(), where it is bounded by mt->num_slots.

Bound the index to the reserved slot range in one place and use that for
every set_bit()/clear_bit() on mt_io_flags.  Dropping the out-of-range
slots is not a functional change: both readers of the slot state mask
with MT_IO_SLOTS_MASK, so bits at or above MT_IO_SLOTS_BITS were never
observable to begin with.

Also correct the comment on the field, which claimed that eight bits were
sufficient because at most 250 slots are supported.

Fixes: 46f781e0d151 ("HID: multitouch: fix sticky fingers")
Cc: stable@vger.kernel.org
Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
---
 drivers/hid/hid-multitouch.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 0495152091e3..463eab9f73cd 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -98,6 +98,7 @@ enum report_mode {
 };
 
 #define MT_IO_SLOTS_MASK		GENMASK(7, 0) /* reserve first 8 bits for slot tracking */
+#define MT_IO_SLOTS_BITS		8 /* bits covered by MT_IO_SLOTS_MASK */
 #define MT_IO_FLAGS_RUNNING		32
 
 static const bool mtrue = true;		/* default for true */
@@ -175,9 +176,10 @@ struct mt_device {
 	struct hid_haptic_device *haptic;	/* haptic related configuration */
 	struct hid_device *hdev;	/* hid_device we're attached to */
 	unsigned long mt_io_flags;	/* mt flags (MT_IO_FLAGS_RUNNING)
-					 * first 8 bits are reserved for keeping the slot
-					 * states, this is fine because we only support up
-					 * to 250 slots (MT_MAX_MAXCONTACT)
+					 * the first MT_IO_SLOTS_BITS bits are reserved
+					 * for keeping the slot states; higher slot
+					 * numbers are not tracked here, see
+					 * mt_io_slot_set()
 					 */
 	__u8 inputmode_value;	/* InputMode HID feature value */
 	__u8 maxcontacts;
@@ -1027,6 +1029,25 @@ static int mt_compute_slot(struct mt_dev
 	return input_mt_get_slot_by_key(input, *slot->contactid);
 }
 
+/*
+ * Only the first MT_IO_SLOTS_BITS bits of mt_io_flags track slot state; the
+ * rest of the word holds unrelated flags such as MT_IO_FLAGS_RUNNING.  Slot
+ * numbers are bounded by td->maxcontacts, which is taken from the HID
+ * CONTACTMAX feature and can be much larger, so the index has to be checked
+ * before touching the word.
+ */
+static void mt_io_slot_set(struct mt_device *td, int slotnum)
+{
+	if (slotnum < MT_IO_SLOTS_BITS)
+		set_bit(slotnum, &td->mt_io_flags);
+}
+
+static void mt_io_slot_clear(struct mt_device *td, int slotnum)
+{
+	if (slotnum < MT_IO_SLOTS_BITS)
+		clear_bit(slotnum, &td->mt_io_flags);
+}
+
 static void mt_release_pending_palms(struct mt_device *td,
 				     struct mt_application *app,
 				     struct input_dev *input)
@@ -1036,7 +1057,7 @@ static void mt_release_pending_palms(str
 
 	for_each_set_bit(slotnum, app->pending_palm_slots, td->maxcontacts) {
 		clear_bit(slotnum, app->pending_palm_slots);
-		clear_bit(slotnum, &td->mt_io_flags);
+		mt_io_slot_clear(td, slotnum);
 
 		input_mt_slot(input, slotnum);
 		input_mt_report_slot_inactive(input);
@@ -1247,9 +1268,9 @@ static int mt_process_slot(struct mt_dev
 		input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, major);
 		input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, minor);
 
-		set_bit(slotnum, &td->mt_io_flags);
+		mt_io_slot_set(td, slotnum);
 	} else {
-		clear_bit(slotnum, &td->mt_io_flags);
+		mt_io_slot_clear(td, slotnum);
 	}
 
 	return 0;
@@ -2062,7 +2083,7 @@ static void mt_release_contacts(struct h
 			for (i = 0; i < mt->num_slots; i++) {
 				input_mt_slot(input_dev, i);
 				input_mt_report_slot_inactive(input_dev);
-				clear_bit(i, &td->mt_io_flags);
+				mt_io_slot_clear(td, i);
 			}
 			input_mt_sync_frame(input_dev);
 			input_sync(input_dev);
-- 
2.43.0


             reply	other threads:[~2026-07-23 22:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23 22:42 Your Name [this message]
2026-07-23 22:54 ` [PATCH] HID: multitouch: bound the slot index before touching mt_io_flags sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260723224211.613112-1-you@example.com \
    --to=qwe.aldo@gmail.com \
    --cc=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox