kernel/git/stable/linux.git/drivers/hid/hid-multitouch.c, branch master

HID: multitouch: Fix stale MT slots when contact count drops to zero

2026-08-25T09:33:02+00:00

The INGENIC 17EF:6161 touchscreen (Lenovo Yoga Book 9 14IAH10) reports HID_DG_CONTACTCOUNT=0 in the frame immediately following the last finger lift rather than omitting the frame entirely. In mt_touch_report() the existing code only updates num_expected when contact_count is non-zero, so a zero contact count on the first packet of a new frame leaves num_expected at its previous value (e.g. 2 for a two-finger gesture). The sync check "num_received >= num_expected" then evaluates "0 >= 2" and never fires, preventing INPUT_MT_DROP_UNUSED from releasing the stale slots. Those slots remain active in the kernel MT layer until the next touch, at which point they are released in a batch alongside the new contact — causing the userspace event consumer to miss the intervening finger-up sequence and corrupt its gesture session state. Fix by resetting num_expected to 0 when contact_count is zero and num_received is still 0 (i.e., this is the first and only packet of the frame, not a continuation packet in a multi-packet sequence). With num_expected=0 the sync check "0 >= 0" fires immediately, calling input_mt_sync_frame() which drops the stale slots via INPUT_MT_DROP_UNUSED. The num_received==0 guard is critical: continuation packets in a multi-packet frame arrive after at least one contact has already been processed (num_received>0), so they are correctly excluded from this path and the existing multi-packet logic is unaffected. Signed-off-by: Dave Carey Tested-by: Dave Carey Signed-off-by: Benjamin Tissoires

Merge branch 'for-7.3/core' into for-linus

2026-08-19T07:27:26+00:00

- fix long-standing force-feedback initialization race across the subsystem (Dmitry Torokhov) - switch to system_dfl_wq (Marco Crivellari)

HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMU

2026-08-14T14:27:59+00:00

Commit b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") assigned MT_CLS_NSMU to the HTIX5288 (0911:5288). This was necessary because the device sometimes fails to send touch release signals when transitioning from >=2 fingers to <2 fingers, and MT_QUIRK_NOT_SEEN_MEANS_UP fixes stuck touches by treating missing contacts as released. However, MT_CLS_NSMU only carries MT_QUIRK_NOT_SEEN_MEANS_UP. It lacks MT_QUIRK_CONTACT_CNT_ACCURATE and MT_QUIRK_IGNORE_DUPLICATES. As a result, after a two-finger scroll finger lift, the device still reports stale coordinates from the released contact in subsequent frames, and the driver overwrites the remaining active slot with those frozen coordinates. The remaining finger appears stuck at the lift position until all fingers are lifted. This was confirmed via evtest on Arch Linux 7.1.3: after TRACKING_ID=-1 for the released slot, every subsequent frame contained duplicate position pairs -- the real moving finger's coordinates followed by the lifted finger's frozen position, both attributed to the active slot. Reclassify the device to MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU (0x0018), which preserves the original MT_QUIRK_NOT_SEEN_MEANS_UP fix while adding the necessary Win8 quirks (CONTACT_CNT_ACCURATE, IGNORE_DUPLICATES), preventing stale coordinate contamination. The additional FORCE_MULTI_INPUT flag is harmless here: it separates the mouse and touchpad collections into distinct input devices, which is the standard behavior libinput already expects. Fixes: b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") Signed-off-by: Xianglin Lin <1021538027@qq.com> Signed-off-by: Jiri Kosina

HID: haptic: move FF initialization into .input_configured()

2026-08-14T12:46:22+00:00

Refactor hid_haptic_init() to take a direct pointer to input_dev and integrate its invocation into hid_haptic_input_configured(). Update hid-multitouch to rely on the refactored callback to perform the force-feedback initialization during the registration loop. This ensures that force-feedback capabilities are set up before the input device is registered and exposed to userspace, closing the registration race. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina

HID: multitouch: fix out-of-bounds bit access on mt_io_flags

2026-07-01T18:36:12+00:00

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. Fixes: 46f781e0d151 ("HID: multitouch: fix sticky fingers") Cc: stable@vger.kernel.org Signed-off-by: Trung Nguyen Signed-off-by: Benjamin Tissoires

Merge branch 'for-7.2/multitouch' into for-linus

2026-06-16T19:52:21+00:00

- UX improvement fixes for Yoga Book 9 (Dave Carey)

HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost contacts

2026-06-10T16:28:19+00:00

The INGENIC 17EF:6161 firmware on the Lenovo Yoga Book 9 14IAH10 does not clear stale contact slots when fingers are lifted. Each HID report contains up to 10 finger slots, but only the first ContactCount slots represent valid contacts; the remaining slots retain TipSwitch=1 with positions from previous touches. Raw HID capture confirms this: across a 60-second capture with repeated multi-finger gestures, 90% of frames had more TipSwitch=1 slots than the reported ContactCount. The ContactCount field itself is always accurate. Add MT_QUIRK_CONTACT_CNT_ACCURATE to the MT_CLS_YOGABOOK9I class so the driver stops processing slots once ContactCount valid contacts have been consumed, discarding the stale ghost entries per HID specification section 17. MT_QUIRK_NOT_SEEN_MEANS_UP (already in the class) ensures that any slot skipped by this guard is released via INPUT_MT_DROP_UNUSED at frame sync. Signed-off-by: Dave Carey Tested-by: Dave Carey Signed-off-by: Jiri Kosina

HID: pass the buffer size to hid_report_raw_event

2026-05-12T16:03:37+00:00

commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") enforced the provided data to be at least the size of the declared buffer in the report descriptor to prevent a buffer overflow. However, we can try to be smarter by providing both the buffer size and the data size, meaning that hid_report_raw_event() can make better decision whether we should plaining reject the buffer (buffer overflow attempt) or if we can safely memset it to 0 and pass it to the rest of the stack. Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires Acked-by: Johan Hovold Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina

HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification

2026-05-12T15:39:26+00:00

The Lenovo Yoga Book 9 14IAH10 (83KJ) (17EF:6161) firmware includes a HID_DG_TOUCHPAD application collection designed for the Windows inbox HID driver's Win8 PTP touchpad mode. On Linux the HID_DG_TOUCHSCREEN collections provide the correct direct-touch interface. The presence of the touchpad collection causes hid-multitouch to misclassify the touchscreen nodes as indirect buttonpads, leaving them non-functional. Within the touchpad collection: - HID_UP_BUTTON usages trigger the touchscreen-with-buttons heuristic that sets INPUT_MT_POINTER on the touchscreen applications. - The HID_DG_TOUCHPAD application itself sets INPUT_MT_POINTER via mt_allocate_application(), propagating to all touchscreen nodes. - A HID_DG_BUTTONTYPE feature (report 0x51) returns MT_BUTTONTYPE_CLICKPAD, setting td->is_buttonpad = true for the entire device. Additionally, the firmware resets if any USB control request arrives while the CDC-ACM interface is initialising (~1.18 s after enumeration). The Win8 compliance blob (0xff00:0xc5) and Contact Count Max feature reports in the touchscreen collections trigger GET_REPORT calls at probe that hit this window. Surface Switch (0x57) and Button Switch (0x58) feature reports are sent by mt_set_modes() on every input-device open and close, repeatedly hitting this window throughout device lifetime. The firmware also leaves a persistent ghost contact in its contact buffer (contact ID 2, fixed coordinates, tip always asserted) on every enumeration. This ghost occupies a multitouch slot and prevents KWin from seeing a clean finger-lift, causing stuck touch state. The ghost is cleared when Input Mode is set via HID_REQ_SET_REPORT at probe. Fix using a report descriptor fixup in mt_report_fixup() and a class definition update: 1. Remove the entire HID_DG_TOUCHPAD application collection. Parsing HID short items from its header to the matching End Collection and closing the gap with memmove eliminates all three BUTTONPAD heuristics and the feature reports within the collection. 2. Neutralize the Win8 compliance blob feature reports remaining in the touchscreen collections by changing Usage Page 0xff00 to 0x0f00, preventing the case 0xff0000c5 branch in mt_feature_mapping() from issuing GET_REPORT. 3. Neutralize the Contact Count Max feature reports by changing usage 0x55 to 0x00; set maxcontacts = 10 in the class definition so the driver uses the correct contact limit without querying the device. 4. Neutralize Surface Switch (0x57) and Button Switch (0x58) feature report usages in the Device Configuration collection so mt_set_modes() does not issue HID_REQ_SET_REPORT for these on every input-device open/close. Input Mode (0x52) is intentionally left intact: the single HID_REQ_SET_REPORT at probe flushes the firmware's contact buffer and clears the persistent ghost contact. By probe time the cdc-acm driver has already satisfied the CDC-ACM init watchdog (~130 ms), so this request arrives safely after the reset window has closed. 5. Add MT_QUIRK_NOT_SEEN_MEANS_UP to the MT_CLS_YOGABOOK9I class so that contacts not present in a frame are released via INPUT_MT_DROP_UNUSED, preventing stale multitouch slots from lingering if the firmware omits a contact from a report. Signed-off-by: Dave Carey Tested-by: Dave Carey Signed-off-by: Jiri Kosina

HID: multitouch: Check to ensure report responses match the request

2026-03-17T10:36:16+00:00

It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early. Signed-off-by: Lee Jones Signed-off-by: Benjamin Tissoires