summaryrefslogtreecommitdiff
path: root/drivers/input
AgeCommit message (Collapse)AuthorFilesLines
5 daysInput: gscps2 - advance receive buffer write indexXu Rao1-0/+1
Commit 44f920069911 ("Input: gscps2 - use guard notation when acquiring spinlock") moved the receive loop into gscps2_read_data() and gscps2_report_data(). While moving the code, it preserved the writes to buffer[ps2port->append], but omitted the following producer index update from the original loop: ps2port->append = (ps2port->append + 1) & BUFFER_SIZE; As a result, append never advances. Since gscps2_report_data() only reports bytes while act != append, the receive buffer always appears empty and no keyboard or mouse data reaches the serio core. Restore the omitted index update. Fixes: 44f920069911 ("Input: gscps2 - use guard notation when acquiring spinlock") Cc: stable@vger.kernel.org # 6.13+ Signed-off-by: Xu Rao <raoxu@uniontech.com> Link: https://patch.msgid.link/460B5655BA580C60+20260624094739.850306-1-raoxu@uniontech.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
5 daysInput: rmi4 - tolerate short register descriptor structureDmitry Torokhov1-12/+25
Some touchpads (e.g. ThinkPad T14 Gen 1) have buggy firmware that reports a register descriptor structure size that is too small for the number of registers it claims to have in the presence map. The remaining bytes in the structure are 0, which with the new strict bounds checking causes the parser to fail with -EIO, aborting the device probe. Tolerate such short reads by dropping the remaining (unparseable or 0-size) registers from the list instead of failing the probe, preventing the driver from trying to use them. Fixes: 0adb483fbf2d ("Input: rmi4 - refactor register descriptor parsing") Reported-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Barry K. Nathan <barryn@pobox.com> Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
5 daysRevert "Input: rmi4 - fix register descriptor address calculation"Dmitry Torokhov1-1/+1
The register descriptor presence register is a packet register, which means its bytes share a single RMI address. It does not occupy consecutive addresses, and the register structure that follows it is located at the next RMI address (presence_address + 1), not (presence_address + presence_size). Revert the incorrect address calculation introduced in commit a98518e72439. Reported-by: "Barry K. Nathan" <barryn@pobox.com> Tested-by: "Barry K. Nathan" <barryn@pobox.com> Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
6 daysInput: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED countBryam Vargas1-1/+1
rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries. Fixes: 3e64fcbdbd10 ("Input: synaptics-rmi4 - limit the range of what GPIOs are buttons") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260614-b4-disp-818d6bda-v1-2-cf39a3615085@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
6 daysInput: synaptics-rmi4 - bound the F3A keymap to the GPIO countBryam Vargas1-1/+1
rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting. Fixes: 9e4c596bfd00 ("Input: synaptics-rmi4 - add support for F3A") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260614-b4-disp-818d6bda-v1-1-cf39a3615085@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
9 daysMerge branch 'next' into for-linusDmitry Torokhov110-1672/+1645
Prepare input updates for 7.2 merge window.
9 daysInput: mms114 - fix touch indexing for MMS134S and MMS136Dmitry Torokhov1-6/+12
The MMS134S and MMS136 touch controllers have an event size of 6 bytes rather than 8 bytes. When __mms114_read_reg() reads the touch data packet from the device into the touch buffer, the events are packed tightly at 6-byte intervals. However, the driver iterates through the events using standard C array indexing (touch[index]), where each element is sizeof(struct mms114_touch) (8 bytes) apart. As a result, any touch events beyond the first one are read from incorrect offsets and parsed improperly. Fix this by explicitly calculating the byte offset for each touch event based on the device's specific event size. Fixes: 53fefdd1d3a3 ("Input: mms114 - support MMS136") Fixes: ab108678195f ("Input: mms114 - support MMS134S") Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260616050912.1531241-1-dmitry.torokhov@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
9 daysInput: elan_i2c - prevent division by zero and arithmetic underflowRanjan Kumar1-6/+30
The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device. Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad") Fixes: e3a9a1290688 ("Input: elan_i2c - do not query the info if they are provided") Signed-off-by: Ranjan Kumar <kumarranja@chromium.org> Link: https://patch.msgid.link/20260612060339.3829666-1-kumarranja@chromium.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
9 daysInput: stop force-feedback timer when unregistering input devicesDmitry Torokhov2-6/+24
Memoryless force-feedback devices use a timer to manage playback of effects. When a driver for such a device is unbound (or the device is unregistered for other reasons), the driver typically frees its private data synchronously. However, the input_dev structure (and its associated force-feedback structures, including the timer) is only freed when the last user closes the corresponding device node. If userspace keeps the device node open while the device is unregistered (e.g., during driver unbind), the force-feedback timer can still fire after the driver's private data has been freed. Introduce a new 'stop' callback to struct ff_device, and call it from input_unregister_device() before the device is deleted. Implement this callback for memoryless devices and synchronously shut down the timer to ensure it is stopped and cannot be rearmed once unregistration happens. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
9 daysInput: iforce - bound the device-reported force-feedback effect indexBryam Vargas1-7/+11
iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: i = data[1] & 0x7f; if (data[1] & 0x80) { if (!test_and_set_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) ... } else if (test_and_clear_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) { ... } The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate "effect started/stopped" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260613-b4-disp-4828d263-v1-1-02320e1a89dd@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
9 daysInput: goodix - clamp the device-reported contact countBryam Vargas1-1/+2
goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration. Fixes: a7ac7c95d468 ("Input: goodix - use max touch number from device config") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260612-b4-disp-6844625d-v1-1-df0aed080c9d@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-16Input: mms114 - reject an oversized device packet sizeBryam Vargas1-0/+6
mms114_interrupt() reads a packet of touch data from the device into a fixed-size on-stack buffer struct mms114_touch touch[MMS114_MAX_TOUCH]; which holds MMS114_MAX_TOUCH (10) events of MMS114_EVENT_SIZE (8) bytes, i.e. 80 bytes. The length of the I2C read into it is taken verbatim from the device: packet_size = mms114_read_reg(data, MMS114_PACKET_SIZE); if (packet_size <= 0) goto out; ... error = __mms114_read_reg(data, MMS114_INFORMATION, packet_size, (u8 *)touch); packet_size is a single device register byte (0x0F) and the only check is the lower bound packet_size <= 0; it is never bounded against the size of touch[]. A malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can report a packet_size of up to 255, so __mms114_read_reg() writes up to 175 bytes past the end of touch[] on the IRQ-thread stack: a stack out-of-bounds write that can overwrite the stack canary, saved registers and the return address. A well-formed device never reports more than the buffer holds, so reject an oversized packet and drop the report, consistent with the handler's other error paths, rather than reading past the buffer. Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver") Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260612-b4-disp-dc4b8dc4-v1-1-d7cb0a828d92@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-14Input: touchwin - reset the packet index on every complete packetBryam Vargas1-6/+9
tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: tw->data[tw->idx++] = data; if (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { ... tw->idx = 0; } The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do. Fixes: 11ea3173d5f2 ("Input: add driver for Touchwin serial touchscreens") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260613-b4-disp-69921bfd-v1-1-82c036899959@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - update formatting in F12Dmitry Torokhov1-60/+60
Clean up various style and formatting issues in the F12 code. Link: https://patch.msgid.link/20260505045952.1570713-20-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - propagate proper error code in F12 sensor tuningDmitry Torokhov1-2/+2
Propagate the actual error code returned by rmi_read() in rmi_f12_read_sensor_tuning() instead of hardcoding -ENODEV. Also, since rmi_read() returns 0 on success, use 'if (ret)' instead of 'if (ret < 0)'. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-19-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - simplify size calculations in F12Dmitry Torokhov1-10/+4
Use min_t() to simplify the clamping logic when calculating the number of objects to process and the number of valid bytes in the attention handler. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-18-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - use sizeof(*ptr) and idiomatic checks in f12 allocatorsDmitry Torokhov1-10/+15
Using sizeof(*ptr) is preferred over sizeof(struct) because it is more robust against type changes. Also switch to checking for allocation failure immediately after each call, and update formatting. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-17-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - use devm_kmalloc for F12 data packet bufferDmitry Torokhov1-1/+1
The sensor->data_pkt buffer is used exclusively to store incoming hardware data during the attention handler, where it is entirely overwritten by either memcpy() or rmi_read_block(). Therefore, there is no need to zero-initialize it during probe. Switch to devm_kmalloc() to avoid the unnecessary memset overhead. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-16-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - use flexible array member for IRQ masks in F12Dmitry Torokhov1-16/+14
Use a flexible array member to allocate the IRQ masks at the end of the f12_data structure, and use the struct_size() helper to calculate the allocation size safely. This replaces manual pointer arithmetic. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-15-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - use unaligned access helpers in F12Dmitry Torokhov1-6/+7
Use get_unaligned_le16() instead of manual bit shifts to construct 16-bit values for max_x, max_y, pitch_x, pitch_y, and object coordinates in the F12 parsing logic. This simplifies the code and makes the endianness explicit. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-14-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - change reg_size type to u32Dmitry Torokhov5-14/+26
Change reg_size from unsigned long to u32 to save space and ensure consistent size across 32-bit and 64-bit architectures, and use DECLARE_BITMAP() for subpacket_map. Also pack the structure by rearranging the members to avoid holes, and use size_add() to prevent potential integer overflows when calculating the total size of registers. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-13-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - refactor F12 probe functionDmitry Torokhov1-116/+81
The F12 probe function contains highly repetitive logic for parsing register descriptors and their individual data items. Refactor the function to use loops to eliminate redundancy, and clarify the code. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-12-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - use kzalloc_flex() for struct rmi_functionDmitry Torokhov1-3/+1
struct rmi_function contains a flexible array member irq_mask. Convert the manual kzalloc size calculation to use the kzalloc_flex() macro. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-11-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - refactor function allocation and registrationDmitry Torokhov3-17/+26
Currently, rmi_create_function() allocates memory for the rmi_function structure, but rmi_register_function() initializes the device via device_initialize(). This split of ownership makes error handling in rmi_create_function() confusing because the caller must be aware that if rmi_register_function() fails, it has already called put_device() to clean up the memory. To make the memory lifecycle explicit and fix potential leaks cleanly introduce rmi_alloc_function() to handle memory allocation and device initialization, and make the caller of rmi_register_function() responsible for cleanup. Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-10-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - use local presence map in rmi_read_register_desc()Dmitry Torokhov2-12/+14
The presence map is only used during the parsing of the register descriptor, so we can make it a local variable instead of storing it in struct rmi_register_descriptor. Also fix the spelling of the constant and the variable name (presence instead of presense). Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-9-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - fix limit in rmi_register_desc_has_subpacket()Dmitry Torokhov1-1/+1
rmi_register_desc_has_subpacket() should use RMI_REG_DESC_SUBPACKET_BITS, not RMI_REG_DESC_PRESENCE_BITS, as the limit for subpacket_map. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-8-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - fix bit count in bitmap_copy()Dmitry Torokhov1-4/+3
bitmap_copy() takes number of bits, not bytes (or longs). Correct the bit count in rmi_driver_set_irq_bits() and rmi_driver_clear_irq_bits(). Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-7-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - iterative IRQ handlerDmitry Torokhov1-16/+16
The current IRQ handler uses recursion to drain the attention FIFO, which can lead to stack overflow on deep queues. Convert it to a loop. Fixes: b908d3cd812a ("Input: synaptics-rmi4 - allow to add attention data") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-6-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - fix memory leak in rmi_set_attn_data()Dmitry Torokhov1-1/+5
kfifo_put() returns 0 if the FIFO is full. In this case, we must free the memory allocated for the attention data to avoid a leak. Fixes: b908d3cd812a ("Input: synaptics-rmi4 - allow to add attention data") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-5-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - initialize attn_fifo properlyDmitry Torokhov1-0/+1
attn_fifo is allocated as part of struct rmi_driver_data using devm_kzalloc in rmi_driver_probe. However, it is never initialized. A zero-initialized kfifo has its mask set to 0, which effectively limits its capacity to 1 element instead of the declared 16. This can lead to lost attention data and memory leaks of the attention data payload if multiple attention events are received before the threaded interrupt handler can process them. Initialize attn_fifo using INIT_KFIFO after allocating rmi_driver_data. Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - fix num_subpackets overflow in register descriptorDmitry Torokhov2-1/+8
RMI_REG_DESC_SUBPACKET_BITS is defined as 296 (37 * BITS_PER_BYTE). This may overflow num_subpackets in struct rmi_register_desc_item which is defined as a u8. Fix this by changing the type of num_subpackets to u16. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-4-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - fix type overflow in register countsDmitry Torokhov1-1/+1
The number of registers in the RMI4 register descriptor is populated by counting the bits in the presence map using bitmap_weight(). Since the presence map can contain up to 256 bits (RMI_REG_DESC_PRESENSE_BITS), storing this count in a u8 can overflow to 0 if all 256 bits are set. Change the num_registers field in struct rmi_register_descriptor from u8 to u16 to prevent potential integer overflow and ensure safe processing of devices reporting large descriptors. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - refactor register descriptor parsingDmitry Torokhov1-48/+76
Factor out parsing a register descriptor item from rmi_read_register_desc() and ensure there are no out-of-bounds accesses. Use get_unaligned_le16() and get_unaligned_le32() for reading multi-byte values. Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-12Input: rmi4 - fix register descriptor address calculationDmitry Torokhov1-1/+1
When reading the register descriptor, the base address is incremented by 1 to read the presence register block. However, after reading the presence register block, the address is incorrectly incremented by only 1 byte (++addr) instead of the actual size of the presence block (size_presence_reg). This causes the subsequent structure block read to read from the wrong memory location if the presence block is larger than 1 byte. Fix this by advancing the address by size_presence_reg. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Link: https://patch.msgid.link/20260505045952.1570713-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-11Input: ipaq-micro-keys - add length check in micro_key_receiveDmitry Torokhov1-0/+3
The driver accesses the message payload (msg[0]) without checking if the length is greater than zero. The parent MFD driver can produce a payload with a length of 0, in which case msg[0] would be uninitialized or stale. Add a check to return early if len is less than 1. Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/aintAvTyw4CVb5hG@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-11Input: ipaq-micro-keys - fix potential deadlockDmitry Torokhov1-2/+2
The driver acquires the micro->lock spinlock in process context (in micro_key_start() and micro_key_stop()) without disabling interrupts. However, this lock is also acquired in hardirq context by the MFD core rx handler (micro_rx_msg()) which is called from the serial ISR. This can lead to a lock inversion deadlock if the interrupt fires on the same CPU while the process context holds the lock. Fix this by using guard(spinlock_irq) instead of guard(spinlock) in micro_key_start() and micro_key_stop() to disable interrupts while holding the lock. Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/aij-pfaKK-Nna7wf@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-11Input: synaptics-rmi4 - unregister function handlers on physical driver ↵Haoxiang Li1-1/+3
registration failure If rmi_register_physical_driver() fails, the current error path unregisters only the RMI bus. The function handlers registered earlier remain registered with the driver core. Add a separate error path to unregister the function handlers before unregistering the bus in this failure case. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260610064633.2837084-1-haoxiang_li2024@163.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-11Input: ads7846 - don't use scratch for tx_buf when clearing registerKris Bahnsen1-3/+2
The workaround for XPT2046 clears the command register, giving the touchscreen controller a NOP. The change incorrectly re-uses the req->scratch variable which is used as rx_buf for xfer[5], so by the time xfer[6] occurs, the contents of req->scratch may not be 0. It was found that the touchscreen controller can end up in a completely unresponsive state due to it being given a command the driver does not expect. Instead, rely on the spi_transfer behavior of tx_buf being NULL to transmit all 0 bits and use the scratch variable for the rx_buf for both the 1 byte command to and 2 byte response from the controller. Also relocates the scratch member of struct ser_req to force it into a different cache line to prevent any potential issues of DMA stepping on unrelated data in other struct members due to sharing the same cache line. This change was tested on real TSC2046 and ADS7843 controllers, but not the XPT2046 the workaround was originally created for. Confirming that the original modification to clear the command register does not impact either real controller. Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle") Cc: stable@vger.kernel.org Co-developed-by: Mark Featherston <mark@embeddedTS.com> Signed-off-by: Mark Featherston <mark@embeddedTS.com> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com> Link: https://patch.msgid.link/20260507164943.760009-1-kris@embeddedTS.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10Input: ads7846 - restore half-duplex supportAaro Koskinen1-2/+166
On some boards, the SPI controller is limited to half-duplex and the driver fails spamming "ads7846 spi2.1: spi_sync --> -22". Restore half-duplex support with multiple SPI transfers. Fixes: 9c9509717b53 ("Input: ads7846 - convert to full duplex") Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Link: https://patch.msgid.link/20260419161848.825831-2-aaro.koskinen@iki.fi Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10Input: remove changelogsElliot Tester2-40/+0
There is no need to keep changelogs in driver sources, they are tracked in git. Signed-off-by: Elliot Tester <elliotctester1@gmail.com> Link: https://patch.msgid.link/20260514193302.117488-1-elliotctester1@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10Input: Drop unused assignments from pnp_device_id arraysUwe Kleine-König (The Capable Hub)2-51/+51
Explicitly assigning .driver_data in drivers that don't use this member is silly and a bit irritating. Drop these. Also simplify the list terminator entry to be just empty to match what most other device_id tables do. There is no changed semantic, not even a change in the compiled result. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/f987c14dea1d3236d3889e5cf96c01eef6a2445d.1781016727.git.u.kleine-koenig@baylibre.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10Input: ipaq-micro-keys - simplify allocationRosen Penev1-10/+7
Embed the keycode array in the struct to have a single allocation. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260609213532.25181-1-rosenp@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-07Input: ims-pcu - fix potential infinite loop in CDC union descriptor parsingDmitry Torokhov1-2/+3
The driver parses CDC union descriptors in ims_pcu_get_cdc_union_desc() by iterating through the extra descriptor data. However, it does not verify that the bLength of each descriptor is at least 2. A malicious device could provide a descriptor with bLength = 0, leading to an infinite loop in the driver. Add a check to ensure bLength is at least 2 before proceeding with parsing. Fixes: 628329d52474 (Input: add IMS Passenger Control Unit driver) Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-07Input: ims-pcu - add response length checksDmitry Torokhov1-6/+81
The driver processes response data from device buffers without verifying that the device actually sent enough data. This can lead to out-of-bounds reads or processing stale data. Add checks for the expected response length before accessing the buffers. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot <sashiko-bot@kernel.org> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-07Input: ims-pcu - fix DMA mapping violation in line setupDmitry Torokhov1-2/+7
In ims_pcu_line_setup(), the driver uses pcu->cmd_buf as a transfer buffer for usb_control_msg(). However, pcu->cmd_buf is embedded in the struct ims_pcu allocation, which violates DMA mapping rules regarding cacheline alignment. Use a heap-allocated buffer for the line coding data instead. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot <sashiko-bot@kernel.org> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-07Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug loggingDmitry Torokhov1-1/+1
The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot <sashiko-bot@kernel.org> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-07Input: ims-pcu - validate control endpoint typeDmitry Torokhov1-0/+6
The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot <sashiko-bot@kernel.org> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-07Input: ims-pcu - fix race condition in reset_device sysfs callbackDmitry Torokhov1-0/+2
The ims_pcu_reset_device() sysfs callback calls ims_pcu_execute_command() without acquiring pcu->cmd_mutex. This can lead to data races and corruption of the shared command buffer if triggered concurrently with other commands. Acquire pcu->cmd_mutex before calling ims_pcu_execute_command(). Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot <sashiko-bot@kernel.org> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-07Input: ims-pcu - fix firmware leak in async updateDmitry Torokhov1-3/+2
The firmware object was not being released if validation failed. Use __free(firmware) to ensure the firmware is always released. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot <sashiko-bot@kernel.org> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-07Input: ims-pcu - fix type confusion in CDC union descriptor parsingDmitry Torokhov1-1/+1
The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot <sashiko-bot@kernel.org> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-07-02 04:23:40 +0300