kernel/linux.git/drivers/hid, branch v6.12.108

HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()

2026-09-02T12:30:59+00:00

commit db8d634128d2ba88d79c0b601e983ebe14bb0519 upstream. magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a "size < 1" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before. Fixes: a462230e16ac ("HID: magicmouse: enable Magic Trackpad support") Link: https://lore.kernel.org/linux-input/20260706181347.700DB1F00A3F@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Jose Villaseñor Montfort Reviewed-by: Alec Hall Tested-by: Alec Hall Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: uclogic: fix use-after-free of inrange_timer on remove

2026-09-02T12:30:59+00:00

[ Upstream commit 506fd50a9027340f0e9dcc587d10ccb03312dba6 ] uclogic_remove() cancels the pen in-range timer and then stops the device: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this "timer re-armed from another path" teardown case. Fixes: 01309e29eb95 ("HID: uclogic: Support in-range reporting emulation") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Jiri Kosina [ changed timer_delete_sync() to del_timer_sync() in the removed line to match the pre-rename API on this branch ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: ft260: fix stack-use-after-return write in I2C read race

2026-09-02T12:30:59+00:00

[ Upstream commit bf3e39df3a397fd82967a31d17c4e02c7feab221 ] ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy. Fixes: 6a82582d9fa4 ("HID: ft260: add usb hid to i2c host bridge driver") Cc: stable@vger.kernel.org Signed-off-by: Raman Varabets Reviewed-by: Michael Zaidman Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: ft260: validate i2c input report length

2026-09-02T12:30:59+00:00

[ Upstream commit 80c4bbb2b38513e9c3d84805fa61a0ee16d79c45 ] Add two checks to ft260_raw_event() to prevent out-of-bounds reads from malicious or malfunctioning devices: First, reject reports shorter than the 2-byte header (report ID + length fields). Without this, even accessing xfer->length on a 1-byte report is an OOB read. Second, validate xfer->length against the actual data capacity of the received HID report. Each I2C data report ID (0xD0 through 0xDE) defines a different report size in the HID descriptor, so the available payload varies per report. A corrupted length field could cause memcpy to read beyond the report buffer. Reported-by: Sebastián Josué Alba Vives Signed-off-by: Michael Zaidman Signed-off-by: Jiri Kosina Stable-dep-of: bf3e39df3a39 ("HID: ft260: fix stack-use-after-return write in I2C read race") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: asus: fix missing hid_is_usb() check

2026-09-02T12:30:59+00:00

[ Upstream commit 02bf61dfb44f17ec187d1da1a82495951bbd12df ] to_usb_interface() can only be used on a hid_device whose parent is really USB; uhid can create devices that identify as being on BUS_USB, but don't actually have a USB parent. Fix the use of to_usb_interface() without a hid_is_usb() check. I have verified that it is currently possible to trigger a kernel splat due to this bug in an ASAN build, and that this commit fixes the issue. Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: asus: simplify RGB init sequence

2026-09-02T12:30:59+00:00

[ Upstream commit 56d1b33e644cca1bedffbc73d28778ed4ae30f64 ] Currently, RGB initialization forks depending on whether a device is NKEY. However, in reality both initialization forks are the same, other than the NKEY initialization initializing the LED_REPORT_ID1, LED_REPORT_ID2 endpoints, and the non-NKEY initialization having a functionality check which is skipped for the NKEY path. Therefore, merge the if blocks, gate the ID1/ID2 initializations behind the NKEY quirk instead, and introduce the functionality check for NKEY devices (it is supported by them). There should be no functional change with this patch. Acked-by: Benjamin Tissoires Signed-off-by: Antheas Kapenekakis Link: https://patch.msgid.link/20260122075044.5070-2-lkml@antheas.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 02bf61dfb44f ("HID: asus: fix missing hid_is_usb() check") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: pidff: fix OOB write when hid->inputs is empty

2026-09-02T12:30:59+00:00

[ Upstream commit 67bb1074e3d2d12fa059a9cc707e89398a4e4704 ] hid_pidff_init_with_quirks() derives its input_dev from list_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user are required. KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe(). Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universal_pidff_probe() propagates the error and unwinds. Discovered by XBOW, triaged by Baul Lee Fixes: f06bf8d94fff ("HID: Add hid-universal-pidff driver and supported device ids") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: pidff: clang-format pass

2026-09-02T12:30:59+00:00

[ Upstream commit ae42428fb4e3d2eed344f0d6fcfa778bc8b8f80a ] Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Stable-dep-of: 67bb1074e3d2 ("HID: pidff: fix OOB write when hid->inputs is empty") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: pidff: Use ARRAY_SIZE macro instead of sizeof

2026-09-02T12:30:59+00:00

[ Upstream commit 8de2cef6d0de8cdddee8d653a18791525af26fad ] Could lead to issues when arrays won't be 8 bit fields Signed-off-by: Tomasz Pakuła Reviewed-by: Oleg Makarenko Signed-off-by: Jiri Kosina Stable-dep-of: 67bb1074e3d2 ("HID: pidff: fix OOB write when hid->inputs is empty") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HID: pidff: Rework pidff_set_time() to fix warnings

2026-09-02T12:30:59+00:00

[ Upstream commit bed72bd240ce77623845853397b89a08f6dc5770 ] Fixes blank line warning from checkpatch.pl script Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Stable-dep-of: 67bb1074e3d2 ("HID: pidff: fix OOB write when hid->inputs is empty") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman