| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Pull HID fixes from Jiri Kosina:
- new device IDs/quirks (Logitech G502X, Elecom M-XT4DRBK, Steelseries
Arctis 7, Asus Rog Z13 Folio, Lenovo Yoga Slim Gen 11)
- fixes for various code issues found by LLMs
* tag 'hid-for-linus-2026092202' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
selftests/hid: add unnumbered variant to the hid_bpf tests
HID: bpf: fix __hid_bpf_hw_check_params report length
selftests/hid: add define for commonly used buf size
HID: amd_sfh: Validate PCI BAR size before mapping
HID: elecom: fix bus type for M-XGL20DLBK
HID: elecom: Add support for ELECOM M-XT4DRBK (018E)
HID: corsair-void: Fix firmware event packet description
HID: i2c-hid: Add i2c-hid-quirk-bad-input-size quirk for 0911:5288 device
HID: hid-oxp: use cancel_delayed_work_sync() in remove
HID: i2c-hid: add reset quirk for Lenovo Yoga Slim 7x Gen 11 keyboard
HID: roccat: fix locking in roccat_connect() and roccat_disconnect()
HID: steelseries: Add support for Arctis 7 (2018)
HID: logitech-hidpp: Add support for G502 X Lightspeed USB mouse
HID: fix semantic patch and improve its performance
HID: alps: fix use-after-free on input2 registration failure
HID: alps: unregister DualPoint Stick input device on remove
HID: winwing: fix use-after-free in force feedback teardown
HID: multitouch: Add report ID mismatch quirk for ASUS ROG Z13 Folio
HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()
HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard
|
|
Turns out that USB, I2C and other transport drivers (except uhid which
just passes the data) still need to have the report ID in the first
byte.
Because they expect the first byte to be the report ID or 0, when the
report ID is 0, they strip that first byte before forwarding to the
device. This means that the transport layer forwards a buffer of size
N-1 to the device, which gets rejected.
Fixes: 5599f8019661 ("HID: bpf: export hid_hw_output_report as a BPF kfunc")
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
|
The amd_sfh driver maps PCI BAR 2 using pcim_iomap_regions() and
subsequently accesses MMIO registers at offsets up to 0x10958 (e.g.,
AMD_P2C_MSG3 at 0x1068C). However, the driver never validates that the BAR
size is large enough to cover these accesses. If the driver is bound to a
device with a smaller BAR 2, this leads to an out-of-bounds memory access
and a page fault during the probe function.
For example, a page fault can occur when reading from privdata->mmio +
AMD_P2C_MSG3 in mp2_select_ops():
BUG: unable to handle page fault for address: ffffc9000390368c
PGD 100000067 P4D 100000067 PUD 1012c1067 PMD 105b64067 PTE 0
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]
RIP: 0010:mp2_select_ops drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:282
[inline]
RIP: 0010:amd_mp2_pci_probe+0x337/0x5f0
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:487
Call Trace:
<TASK>
local_pci_probe drivers/pci/pci-driver.c:332 [inline]
pci_call_probe drivers/pci/pci-driver.c:394 [inline]
__pci_device_probe drivers/pci/pci-driver.c:455 [inline]
pci_device_probe+0x431/0xc90 drivers/pci/pci-driver.c:489
Fix this by verifying that the length of BAR 2 is at least 128KB before
attempting to map it. Since the maximum accessed offset is 0x10958, and PCI
BAR sizes are powers of 2, any legitimate hardware will have a BAR size of
at least 128KB.
Fixes: 4f567b9f8141 ("SFH: PCIe driver to add support of AMD sensor fusion hub")
Assisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+4eadd4dfe9e66522bae8@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=4eadd4dfe9e66522bae8
Link: https://syzkaller.appspot.com/ai_job?id=3bc1c45c-548f-4ab5-8243-d2c8ec321d6c
Signed-off-by: Slawomir Stepien <sst@poczta.fm>
Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Link: https://syzkaller.appspot.com/bug?extid=4eadd4dfe9e66522bae8
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The M-XGL20DLBK is matched as a USB device by hid-elecom, but
its entry in hid_have_special_driver[] uses HID_BLUETOOTH_DEVICE.
This prevents the special-driver quirk entry from matching the USB
device handled by hid-elecom. Use HID_USB_DEVICE there as well.
Fixes: 55633e681afb ("HID: elecom: add support for EX-G M-XGL20DLBK wireless mouse")
Signed-off-by: Oscar Priego Verdugo <oscar.priegov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The 2025 revision of the left-handed EX-G wireless trackball
(M-XT4DRBK-G) reports USB ID 056e:018e instead of 056e:00fd. Its report
descriptor declares an 8-bit button field (Report Count 8) but only five
usages (Usage Maximum 5), so the sixth (Fn) button ends up as a
duplicate of button 5 and is unusable.
The report descriptor has the same layout as the M-XT3DRBK 018C
(button usage maximum at offset 16, button report count at 22, button
report size at 24, padding report size at 30), so reuse that fixup.
Rename the existing M_XT4DRBK define to M_XT4DRBK_00FD to match the
convention used for the other EX-G revisions.
Tested on a Raspberry Pi 5 with the same fixup in an
out-of-tree module on 6.12 (6.12.96+rpt-rpi-2712);
all six buttons are reported after the fix, and they
work (tested with xev as well).
Report descriptor as sent by the device, pre-fix (056e:018e,
215 bytes):
05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01
29 05 15 00 25 01 95 08 75 01 81 02 95 01 75 00
81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10
95 02 81 06 C0 A1 00 05 01 09 38 15 81 25 7F 75
08 95 01 81 06 C0 A1 00 05 0C 0A 38 02 95 01 75
08 15 81 25 7F 81 06 C0 C0 06 01 FF 09 00 A1 01
85 02 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0
05 0C 09 01 A1 01 85 05 15 00 26 3C 02 19 00 2A
3C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85
03 19 81 29 83 15 00 25 01 95 03 75 01 81 02 95
01 75 05 81 01 C0 06 BC FF 09 88 A1 01 85 04 95
01 75 08 15 00 26 FF 00 19 00 2A FF 00 81 00 C0
06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00
75 08 95 07 B1 02 C0
Assisted-by: LLM
Signed-off-by: Berke Durak <berke.durak@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The size was incorrectly stated as 4 bytes since the ID was missed out.
Add the ID in and correct the indices for the firmware versions.
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
I have recently acquired a cheap Apollo Lake-based laptop that uses a
Hynitron CST128-A touchpad controller. While booting from a Debian LiveCD,
the kernel log is flooded with the following error (though the touchpad
works well):
i2c_hid_acpi i2c-ALPS0001:00: i2c_hid_get_input: incomplete report (27/42405)
The CST128-A was identified via ACPI as ALPS0001:00, and the I2C HID
device ID (0911:5288) was shared with the Hantick 5288.
Add the I2C_HID_QUIRK_BAD_INPUT_SIZE quirk option to the existing Hantick
5288 quirk entry to suppress the kernel log flood.
Signed-off-by: Youth Cao <cocoh2os08@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
oxp_hid_remove() uses cancel_delayed_work() for all three delayed work
items. cancel_delayed_work() only dequeues a pending work item without
waiting for a currently executing callback to finish. If any of the
work callbacks (oxp_rgb_queue_fn, oxp_btn_queue_fn, oxp_mcu_init_fn) is
running at the time of removal, the callback continues executing
concurrently with hid_hw_close() and hid_hw_stop(), accessing the HID
device after it has been closed and stopped.
Use cancel_delayed_work_sync() instead to ensure that any in-progress
work callback completes before device teardown proceeds.
Fixes: 84910c459d65 ("HID: hid-oxp: Add OneXPlayer configuration driver")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Link: https://lore.kernel.org/r/20260804-oxp-fix-v2-1-b2d56e4c8a2c@cherr.cc
Link: https://lore.kernel.org/r/20260804-oxp-fix-v1-1-51a4fe787167@cherr.cc
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The ITE controller behind the keyboard of the Lenovo Yoga Slim 7x Gen 11
(048d:83db) carries out a reset but never raises the interrupt that
acknowledges it. i2c_hid_finish_hwreset() therefore waits out its full
one second timeout and logs "device did not ack reset within 1000 ms" on
every probe and every resume, before the keyboard comes up regardless.
Set I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for it, as is already done for
several other ITE parts, so the reset is followed by a fixed 100 ms sleep
instead.
Signed-off-by: Oleg Keri <okerixx@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Extend critical section in roccat_connect() to ensure that partially
initialized 'struct roccat_device' is never exposed in 'devices' list,
and do the same in roccat_disconnect() to avoid racy 'devices' access
against roccat_release().
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The headset reports connection and battery status on HID interface
5. When the device is disconnected, ignore incoming battery
reports as they will incorrectly report battery level 0.
Clamp overreported battery values to 100% and add USB ID 1038:12ad
to the driver's device tables.
Signed-off-by: Erik Håkansson <erikhakan@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The G502 X Lightspeed enumerates as 046d:c098 when connected with its
cable. Add the id so the driver handles the wired device.
Signed-off-by: Andres Diaz <andresd.diaz16@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
alps_input_configured() stores data->input2 before calling
input_register_device(). If registration fails, input_free_device()
frees the input device but data->input2 still points to the freed memory.
alps_input_configured() calls hid_hw_open() before allocating input2, so
URBs are already active and raw_event can fire during the failure window.
A U1_SP_ABSOLUTE_REPORT_ID report arriving then causes u1_raw_event()
to dereference the freed data->input2 -> use-after-free.
Fix by only storing input2 into drvdata after successful registration
and adding a NULL guard in the raw_event path.
Fixes: 2562756dde55 ("HID: add Alps I2C HID Touchpad-Stick support")
Cc: stable@vger.kernel.org
Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
alps_input_configured() allocates a second input device ("DualPoint
Stick") with input_allocate_device() and registers it, but the
alps_driver struct has no .remove handler and input2 is not tracked in
hdev->inputs. The default remove path (hid_hw_stop -> hidinput_disconnect)
only iterates hdev->inputs, so input2 is never unregistered and leaks
on every device removal.
Add a .remove handler that stops the device first (preventing URB
callbacks from touching input2 during teardown) and then unregisters
input2.
Fixes: 2562756dde55 ("HID: add Alps I2C HID Touchpad-Stick support")
Cc: stable@vger.kernel.org
Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
winwing_init_ff() passes the driver's private data, allocated with
devm_kzalloc() in winwing_probe(), as the effect context to
input_ff_create_memless(). The memoryless force-feedback core takes
ownership of that pointer and frees it with kfree() from
input_ff_destroy() (ml_ff_destroy()) when the input device is
destroyed.
Freeing a devm-managed allocation with kfree() is an invalid free, and
the same object is then released again by devres when the HID device is
torn down, a double free. As the allocation also embeds the LED class
devices, their timers and work item live on freed memory and the slab
gets corrupted. This triggers on unbind, rmmod, hot-unplug and on system
suspend, where the firmware cache walks the now-corrupt devres list.
KASAN reports:
BUG: KASAN: invalid-free in input_ff_destroy
Allocated by task N:
winwing_probe
Pass NULL as the memless context instead and fetch the driver data from
the input device in winwing_play_effect(): the HID core already stores
the hid_device as the input device's drvdata. The force-feedback core
then owns nothing that it must not free.
Fixes: 42d020b54edc ("HID: winwing: Enable rumble effects")
Signed-off-by: René Onier <f3nr1l@me.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Commit e716edafedad ("HID: multitouch: Check to ensure report
responses match the request") introduced validating GET_FEATURE
responses return the requested report ID.
ASUS ROG Z13 Flow (2025) GZ302EA touchpad (USB 0b05:1a30) returns
a different report ID for Win8 feature request. Before this check,
the response was still processed and allowed device to switch into
its full Touchpad Precision mode.
After the validation, the response is discarded before
hid_report_raw_event() processes it and device remains in fallback
mode and no longer exposes ABS_MT_SLOT, ABS_MT_TOOL_TYPE or the
multi-finger BTN_TOOL_* capabilities for palm rejection.
Add a device quirk to allow the known firmware behavior for
this device while preserving report ID validation for all other
devices.
The device previously matched the generic MT_CLS_WIN_8 entry, so
base the new class on MT_CLS_WIN_8 to keep it on the same quirk set
as before the regression. MT_QUIRK_CONFIDENCE must be set
explicitly: it is normally enabled by the class name check in
mt_touch_input_mapping(), which only matches the MT_CLS_WIN_8*
names, and it is what makes ABS_MT_TOOL_TYPE available for
touchpads.
Fixes: e716edafedad ("HID: multitouch: Check to ensure report responses match the request")
Signed-off-by: Lovekesh Solanki <lovekeshsolanki00@gmail.com>
Reported-by: mayhemandcoffee <mayhemandcoffee@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221774
Tested-by: mayhemandcoffee <mayhemandcoffee@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221774
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The 'wacom_wac_pen_serial_enforce()' function may calculate and pass an
invalid offset to hid_field_extract(), resulting in memory reads at
incorrect addresses -- possibly beyond the end of the report. If a
field in the HID descriptor lists more usages than its Report Count
actually reserves space for, the function's inner 'j' will walk past
the end of the field:
for (i = 0; i < report->maxfield; i++) {
for (j = 0; j < report->field[i]->maxusage; j++) {
...
value = hid_field_extract(hdev, raw_data + 1,
offset + j * size, size);
A descriptor listing 12288 usages against Report Count 1 has the loop
extract the usage at index 12287 from bit offset 98296 -- about 12 KB
past a 2-byte received report. The value is stored in
wacom_wac->serial[0] and can reach userspace as an MSC_SERIAL event,
making this an information disclosure.
Clamp the loop to field->report_count, the number of value slots the
report holds. Value slots past the last declared usage are still
scanned; they reuse that usage (HID 1.11, 6.2.2.8).
Verified on v6.12.105 with a UHID reproducer: a 2-byte report from
such a descriptor trips KASAN before the patch and not after it.
Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing")
Suggested-by: Jason Gerecke <killertofu@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Assisted-by: GLM:glm-5.3
Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The SDINNOVATION gaming keyboard (USB ID 36ae:feab) stops reporting
input events after its RGB lighting mode is switched about twice.
Disabling USB autosuspend and unbinding the other HID interfaces make
no difference; the issue does not occur on Windows.
HID_QUIRK_ALWAYS_POLL alone resolves it, verified on 7.1.8 via
usbhid.quirks=0x36ae:0xfeab:0x400.
Reported-by: Marco Carvalho <marcocarvalho.web@gmail.com>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2514627
Cc: stable@vger.kernel.org
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
|
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
Pull HID fixes from Benjamin Tissoires:
- hid-hyperv build fixes on certain configs (Jiri Kosina)
- HID-BPF fix and selftests now that the bpf verifier is more
restrictive (Benjamin Tissoires)
- Some AI detected fixes for OOB, errors and validation (Ibrahim
Hashimov, Shen Yongchao, Wei Jie Law)
- various device fixes (Dave Carey and Vadim Klishko)
* tag 'hid-for-linus-2026090401' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
HID: bpf: serialize device reference release in struct_ops destroy path
HID: rmi: fix OOB access with undersized RMI reports
selftests/hid: prepare test_rdesc_fixup_get_data_overflow for the new verifier
selftests/hid: Add a test to ensure we can write fields in hid_device
HID: bpf: mark struct hid_device as safe BPF pointer
HID: wacom: validate report length in wacom_intuos_pro2_bt_irq
HID: multitouch: Fix stale MT slots when contact count drops to zero
HID: i2c-hid: Add a quirk for a Cirque I2C device.
HID: hyperv: make pointer arithmetics understandable for FORTIFY_SOURCE
HID: hyperv: fix build breakage with certain configs
|
|
__hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the
same registration reference, double-putting struct hid_device and
freeing it while hid_destroy_device() still uses it. Serialize the
remove/NULL decision under hdev->bpf.prog_list_lock so exactly one
path releases each registration reference: unreg re-checks ops->hdev
under the lock and returns without putting when the destroy path
already cleared it; all put_device() calls happen after the lock is
dropped, which is safe because a concurrent unreg then observes
ops->hdev == NULL under the lock.
Background: each successful attach (hid_bpf_ops_reg) acquires one
device reference (hid_get_device()). Two paths can release it:
- device destruction: hid_destroy_device() -> hid_bpf_destroy_device()
-> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list
under rcu_read_lock() and drops one reference per attached program;
- BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls
st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for
its own registration.
The coordination handshake (e->hdev = NULL on the destroy side vs
"if (!hdev) return" on the unreg side) is a TOCTOU check: the two
paths run under different lock domains (rcu_read_lock vs
prog_list_lock), so a concurrent unreg can read ops->hdev as
non-NULL, block on prog_list_lock, and then proceed while the
destroy traversal executes - both paths then drop the same
reference. The refcount reaches zero legitimately (each decrement
is individually valid), so no refcount_t saturation fires: the
device is simply freed while the transport is still inside
hid_destroy_device(), and subsequent teardown touches freed memory.
The fix serializes the remove/NULL decision under prog_list_lock on
both sides and moves the destroy-side puts outside the lock. With
the lock held, plain reads/writes of ops->hdev are sufficient; no
READ_ONCE/WRITE_ONCE are added, keeping the patch minimal.
Unlocked-read safety: the unlocked read of ops->hdev at the top of
hid_bpf_unreg() cannot touch a freed device, because the unreg path
itself still holds this registration's reference (released only by
its own hid_put_device() after the lock is dropped), and a destroy
traversal that already cleared ops->hdev makes the lock-internal
re-check return early without any put. At most one of the two
paths releases each registration reference.
Fixes: ebc0d8093e8c ("HID: bpf: implement HID-BPF through bpf_struct_ops")
Cc: stable@vger.kernel.org
Signed-off-by: Shen Yongchao <grayhat@foxmail.com>
Assisted-by: Hermes:kimi-k3
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
|
The hid-rmi driver sizes its writeReport/readReport buffer purely from
the report descriptor supplied by the device, with no minimum bound:
data->input_report_size = hid_report_len(input_report);
data->output_report_size = hid_report_len(output_report);
alloc_size = data->output_report_size + data->input_report_size;
data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL);
data->readReport = data->writeReport + data->output_report_size;
but then reads and writes fixed offsets into it. A device declaring a
1-byte output and a 1-byte input report makes hid_report_len() return 2
for each, so alloc_size is 4, while rmi_set_page() -- reached
unconditionally at probe time through rmi_input_configured() -- stores
writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since
readReport lives at writeReport + output_report_size, those stores also
corrupt the window the next reply is parsed out of.
The read path is worse: the copy length comes from readReport[1], which
the device fills in and can be up to 255, and the copy starts at
&readReport[2] with no regard for input_report_size, so it runs past the
end of the allocation into adjacent slab objects. This does not even
need a lying device -- rmi_f01_probe() issues a fixed 21-byte register
read, so any device declaring an input report smaller than 23 bytes
reads out of bounds even when it answers truthfully. Those bytes become
the register values the RMI core acts on: rmi_f01_probe() prints them to
the kernel log as the product id and exports them through the mode 0444
sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends
them back to the device as the interrupt mask, so an undersized report
descriptor leaks heap contents both to unprivileged userspace and to the
device itself.
The write path has no bound either: rmi_hid_write_block() copies an
unbounded len to &writeReport[4], and the largest caller a device can
drive at probe time is rmi_driver_set_irq_bits(), whose length is
derived from the interrupt source counts the device declares in its Page
Description Table.
Finally, the read loop cannot terminate on a zero-length reply: such a
reply copies nothing and advances neither bytes_read nor bytes_needed,
and because a reply did arrive the one second wait_event_timeout() does
not fire either, so a device answering 0 forever keeps the loop running
inside the probe worker with page_mutex held. khungtaskd does not
notice, because every reply wakes the task.
Reject reports too small for what the driver builds -- 6 output bytes
for the write reports and 3 input bytes for the read handshake -- at
probe time, clamp the write and the read copy to the report sizes the
device declared, and treat a zero-length reply as an error. A device
refused this way is started as an ordinary HID device, like one that
does not carry the RMI report ids at all.
RMI_DEVICE must not be left set in device_flags on that path, because
rmi_input_configured() would then run the RMI setup and reach
rmi_set_page(), which writes the writeReport buffer the refusal just
skipped allocating. The bit can arrive set: rmi_probe() copies
id->driver_data into device_flags before the report checks, and a bind
through the new_id sysfs attribute can supply driver_data with
RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so
RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the
three jumps to start that predate this patch are covered as well.
The error path also clears RMI_READ_DATA_PENDING on its way out, because
that flag is what the wait at the top of the loop tests: leaving it set
would make every later wait_event_timeout() return immediately on the
stale reply and kill the read path for the rest of the device's life.
Clamping does not regress working hardware: the read loop already
handles a reply carrying fewer bytes than requested, and a write longer
than the output report was overrunning the buffer already.
Verified on v6.12.69 and on v6.12.105 built with CONFIG_KASAN=y and
booted kasan_multi_shot, whose hid-rmi.c is identical to mainline here.
An emulated RMI4 device driven over /dev/uhid, and the same device again
over dummy_hcd plus raw-gadget, give identical results:
BUG: KASAN: slab-out-of-bounds in rmi_hid_read_block+0x409/0x750 [hid_rmi]
Read of size 21 at addr ffff88800bf33bba by task kworker/0:3/285
__asan_memcpy+0x23/0x60
rmi_hid_read_block+0x409/0x750 [hid_rmi]
rmi_f01_probe+0x5dd/0x1dc0 [rmi_core]
BUG: KASAN: slab-out-of-bounds in rmi_hid_write_block+0x1a9/0x350 [hid_rmi]
Write of size 35 at addr ffff88810a2b24ac by task kworker/1:10/666
__asan_memcpy+0x3c/0x60
rmi_hid_write_block+0x1a9/0x350 [hid_rmi]
rmi_driver_set_irq_bits+0x1f6/0x4d0 [rmi_core]
rmi_driver_probe+0x636/0xbf0 [rmi_core]
rmi_input_configured+0x184/0x2e0 [hid_rmi]
rmi_probe+0x952/0xcf0 [hid_rmi]
and, for the zero-length reply, a probe worker left in D state in
rmi_hid_read_block() after 225 replies at 200 ms intervals.
After this change the undersized descriptor is refused at probe with
"rmi reports too small (out=2 in=2)", the oversized read and write are
both rejected, the zero-length reply fails the read with -EIO while
later reads on the same device keep working, and a device declaring
reports large enough for a 21-byte register read still probes normally
and reports its real product id. A device bound through new_id with
RMI_DEVICE in its driver_data no longer reaches rmi_set_page() with an
unallocated writeReport either.
Link: https://lore.kernel.org/linux-input/20260822121007.153988-1-98lawweijie@gmail.com/
Link: https://lore.kernel.org/linux-input/00a489f38b240624dcb5a4bae36a53fcba9cfb47.1787549195.git.98lawweijie@gmail.com/
Link: https://lore.kernel.org/linux-input/20260824122708.76168-1-98lawweijie@gmail.com/
Link: https://lore.kernel.org/linux-input/20260825060954.104890-1-98lawweijie@gmail.com/
Fixes: 9fb6bf02e3ad ("HID: rmi: introduce RMI driver for Synaptics touchpads")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Assisted-by: GLM:glm-5.3
Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Commit ee9ad135b208 ("bpf: Reject a store through a fault prone
pointer") in the BPF tree makes the verifier reject any writes to
hid_device->{name,uniq,phys}. A simple solution is to mark the struct
hid_device as safe from a BPF point of view.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
|
wacom_intuos_pro2_bt_irq() receives the wire report length in `len`
but never consults it before parsing. After the report-id gate it
unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by
features.type, a fixed chain of sub-parsers, none of which receive
`len`:
wacom_intuos_pro2_bt_pen(wacom);
if (type == INTUOSP2_BT || type == INTUOSP2S_BT) {
wacom_intuos_pro2_bt_touch(wacom);
wacom_intuos_pro2_bt_pad(wacom);
wacom_intuos_pro2_bt_battery(wacom);
} else {
wacom_intuos_gen3_bt_pad(wacom);
wacom_intuos_gen3_bt_battery(wacom);
}
Each sub-parser dereferences wacom->data at fixed offsets. The furthest
byte touched on each branch is:
INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285]
(the touchring byte), so the report must be at least 286 bytes;
INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45],
so the report must be at least 46 bytes.
features.type is selected from the VID/PID id_table entry and
wacom_setup_device_quirks() force-registers the pen/pad/touch inputs
for that type independent of the report descriptor, so a malicious or
malfunctioning paired/spoofed Bluetooth peripheral can advertise that
VID/PID and send an undersized report that still satisfies the
data[0] == 0x80/0x81 gate. The driver then reads past the received
report and forwards the bytes to userspace via evdev (MSC_SERIAL /
ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds
read with a concrete userspace read-back channel, and a true
out-of-bounds read on transports whose backing buffer is sized to the
(small) report descriptor rather than a fixed-size staging buffer.
This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix
out-of-bounds read in wacom_intuos_bt_irq") already hardened in the
sibling wacom_intuos_bt_irq(), which guards each report id against its
minimum length before parsing.
Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject
reports shorter than the furthest offset the selected branch actually
dereferences, warn, and bail out. Because the whole pen/touch/pad/
battery chain runs unconditionally per branch, a single up-front check
against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT,
46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on
a short report also skips those calls for the same malformed report,
which is the safe, conservative behavior.
Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Cc: stable@vger.kernel.org
Signed-off-by: Ibrahim Hashimov <security@auditcode.ai>
Assisted-by: AuditCode-AI:2026.07
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
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 <carvsdriver@gmail.com>
Tested-by: Dave Carey <carvsdriver@gmail.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
|
Cirque touchpads with PID D0C1 generate an error when probed
by the I2C HID driver, resulting in no hidraw device created.
Adding I2C_HID_QUIRK_NO_IRQ_AFTER_RESET fixes the issue.
Signed-off-by: Vadim Klishko <vadim@cirque.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
|
Pull x86 platform driver updates from Ilpo Järvinen
"Highlights:
Major refactoring effort: stop setting acpi_device_name/class() and
pnp.device_class to facilitate their eventual removal
Many rollback/remove path fixes (presumably mostly found by AI)
Miscellaneous cleanups / refactoring / improvements
amd/halo:
- Add Halo RGB LED driver
amd/hsmp:
- Properly serialize probe, remove, and data paths
- Add support for protocol v7 used by Family 1AH Model 80H
- Fix error checking corner cases (largely from AI review)
- Reject negative power cap
amd/pmc:
- Improve behavior on platforms that do not support STB
- Add T14 Gen2 AMD (20XL) to s2idle quirk list
amd/pmf:
- Add ioctl interface to retrieve device metrics
- Add support for new metrics tables used by Family 1AH Model 80H
qcom-hamoa-ec (arm64):
- Reject short responses
asus-nb-wmi:
- Support ProArt key on ASUS ProArt PX13
asus-armoury:
- Gate PPT writes behind active fan curve
- Add power limits for more models
dell-wmi-base:
- Fix handling of ultra performance key
dell-wmi-sysman:
- Don't hex dump attribute security buffer
hp-bioscfg:
- Various fixes
- Improve reduced ACPI packages support (necessary for HP EliteBook 840 G2)
lg-laptop:
- Fix LED resource handling
- Add support for events used in newer models
- Fix keyboard backlight support on LG Gram 16T90SP
hp-wmi:
- Generalize thermal params to board params
- Manage CPU and GPU PWM independently
- Add GPU MUX switch support
- Add Victus 15-fb0xxx support
- Add OMEN MAX 16-ak0xxx, OMEN 16-n0xxx, OMEN 16-wd0xxx, OMEN
16-wf0xxx, and OMEN board ID 8D88 support
- Add OMEN Transcend 16-u0xxx support
huawei:
- Add support for Fn-lock ACPI interface found on newer Huawei
laptops such as MateBook 14 2024
ISST:
- Improve input validation (many fixes)
- Disallow SST-CP (core-power) feature if perf profile add fails
lenovo/yb9-kbdock:
- Add driver for Yoga Book 9 14IAH10
lenovo/ymc:
- Extend hinge switch query to support Yoga 9 2-in-1 14IPH11
- Prevent loading on Yoga Book 9 14IAH10 to avoid duplicated input
nodes
msi-ec:
- Add MSI Raider A18 HX A9WJG and MSI Katana GF76 11UEK support
msi-wmi:
- Add MSI Claw M-Center keys support
oxpec:
- Add support for OneXPlayer X2 Mini Pro
redmi-wmi:
- Report kbd backlight cycle, OEM preset power mode, and FnLock
toggle events to userspace
samsung-galaxybook:
- Add Samsung Galaxy Book6 Pro support
thinkpad_acpi:
- Add USB-C Security support
uniwill-laptop:
- Add keyboard backlight, AC auto boot, and USB powershare support
- Add MACHENIKE L16 Pro, AiStone X4SP4NAL, and Avell A60 MUV support
- Make lightbar max brightness configurable and add support for
LAPQC71A/B"
* tag 'platform-drivers-x86-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (152 commits)
platform/x86: think-lmi: Fix current password length check
platform/x86: redmi-wmi: report EC state change events
MAINTAINERS: update Intel PMC Core maintainer contact
platform/x86: oxpec: Add support for OneXPlayer X2 Mini Pro
platform/x86: thinkpad_acpi: Fix fan speed reporting on Edge E330
platform/x86: msi-ec: Add MSI Katana GF76 11UEK EC firmware
platform/x86: think-lmi: Fix certificate thumbprint sysfs output
mlxbf-bootctl: fix the build error with FIELD_PREP()
platform/x86: think-lmi: Free system certificate signatures
platform/x86: ISST: Add a NULL check for sst_inst[]
platform/x86: ISST: Return error during profile addition
platform/x86: ISST: Just allow 2 bits for SST feature enable
platform/x86: ISST: Use PP level enable mask
platform/x86: ISST: Validate parameter for frequency and priority
platform/x86: ISST: Validate parameter for core power state
platform/x86: ISST: Validate max level for set feature
platform/x86: ISST: Validate logical CPU id and clos id
platform/x86: ISST: Validate level in perf mask ioctls
platform/x86: ISST: Validate socket ID in clos_assoc ioctl
platform/x86/amd/hsmp: Reject negative power cap writes in hwmon
...
|
|
Commit 83df7b5fa6735b5084ecd2 ("HID: hyperv: add KUnit coverage for device info
bounds") introduced this piece of code
report = ((u8 *)&info->hid_descriptor) + info->hid_descriptor.bLength;
memset(report, 0x42, 4);
to populate the report, making use of the fact that the report
&info->hid_descriptor points to a struct hid_descriptor (which is a fixed-size
struct).
GCC's FORTIFY_SOURCE infer the object size from that specific struct field
rather than the outer dynamically allocated info buffer. As a result, writing
past sizeof(struct hid_descriptor) triggers the __write_overflow_field warning.
Calculate the pointer offset using info directly, so the compiler evaluates the
memory bounds against the allocated flexible layout of struct
synthhid_device_info instead of the nested struct.
Fixes: 83df7b5fa6735b5084ecd2 ("HID: hyperv: add KUnit coverage for device info bounds")
Reported-by: Jürgen Groß <jgross@suse.com>
Tested-by: Jürgen Groß <jgross@suse.com>
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
If CONFIG_HID_HYPERV is built-in (=y) while CONFIG_KUNIT is built as a module
(=m), the linker fails to resolve kunit_mem_assert_format when creating
vmlinux.
Fix the dependencies in Kconfig.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608190536.d9qCkWWc-lkp@intel.com/
Fixes: 83df7b5fa6735b5084ecd2 ("HID: hyperv: add KUnit coverage for device info bounds")
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Pull bpf updates from Daniel Borkmann:
"Major changes:
- Redesign the verifier error reporting: failures now carry source
and instruction annotations along with the causal event history
that led to them, making program rejections far easier to debug and
repair (Kumar Kartikeya Dwivedi)
- Add arena argument support to kfuncs and struct_ops through the new
__arena and __arena__nullable suffixes (Tejun Heo, Puranjay Mohan,
Kumar Kartikeya Dwivedi, Ihor Solodrai)
- Signed BPF program loader rework to accommodate both BPF and
security community needs where the kernel runs the signature
verification at BPF_PROG_LOAD time before the LSM admission hook
(Daniel Borkmann)
- Add a set of ksock kfuncs which let BPF LSM and syscall programs
create, connect and send on UDP sockets in order to emit telemetry
data (Mahe Tardy)
- Unify helper and kfunc call argument verification and classify
kfunc arguments purely from BTF into a generated bpf_func_proto
which is computed once at add-call time (Amery Hung)
Other features and fixes:
- Enable EXECMEM_ROX_CACHE for BPF allocations on x86 (Mike Rapoport)
- Add bidirectional VLAN support to bpf_fib_lookup() through the new
BPF_FIB_LOOKUP_VLAN and BPF_FIB_LOOKUP_VLAN_INPUT flags (Avinash
Duduskar)
- Infer zext_dst from static register liveness analysis to fix 32-bit
zero-extension semantics, and remove the artificial limitations on
pointer types eligible for spilling (Eduard Zingerman)
- Inline the numeric open-coded iterator kfuncs so that bpf_for()
loops no longer pay a kfunc call on every iteration (Puranjay
Mohan)
- Add an arena-based bitmap data structure to libarena along with
serial and parallel selftests (Emil Tsalapatis)
- Teach resolve_btfids to discover kfuncs from the kernel's BTF ID
sets and to emit kfunc BTF decl tags, reducing the kernel build's
dependency on pahole features (Ihor Solodrai)
- Add BPF_F_ADJ_ROOM_DECAP_* flags to bpf_skb_adjust_room() so that
tunnel decapsulation can update the GSO and encapsulation state of
the skb (Nick Hudson)
- Fix the ring buffer pending_pos walk and the available-data
accounting on 32-bit position wrap (Israel Téllez García)
- Add memory usage accounting for arena maps and fix an mmap_lock
deadlock on arena lock failure (Jiayuan Chen)
- Add tracing_multi link info support to the kernel UAPI and bpftool,
and refactor the stack map code to run with preemption disabled
(Jiri Olsa)
- Support BPF_F_EGRESS in bpf_redirect_peer() to emit the skb in the
egress direction of the target's peer device (Jordan Rife)
- Add a KF_SPINLOCK_SAFE kfunc flag so that providers, in particular
modules, can declare kfuncs safe to call under bpf_spin_lock
instead of relying on the verifier's hard-coded allowlist (Kaitao
Cheng)
- Introduce global percpu data for BPF programs with libbpf probing
and bpftool skeleton support, and stop exposing uninitialized
kernel heap memory when copying per-CPU map values (Leon Hwang)
- Add s390 JIT support for load-acquire and store-release
instructions (Maxim Khmelevskii)
- Fix a CFI mismatch in the task work callback and an arm64 KASAN
false positive after bpf_throw() (Mykyta Yatsenko)
- Reject writes through untrusted BTF pointers and bound the
rdonly/rdwr_buf_size kfunc arguments (Nicholas Dudar)
- Invalidate RCU pointers only after the final spin unlock and
account for preempt and IRQ disabled regions as overlapping RCU
protection (Ning Ding)
- Support mixing bpf2bpf calls and tail calls on RV64, add signed
operations and 32-bit atomics to the RV32 JIT, and add timed
may_goto support (Pu Lehui, Kuan-Wei Chiu, Feng Jiang)
- Fix a use-after-free on mm_struct in bpf_find_vma() for foreign
tasks and an mmap_lock leak in the irq_work path (Sanghyun Park)
- Populate mmap-able BPF array map memory lazily which makes mmap()
O(1) instead of proportional to the map size (Song Liu)
- Introduce a jit_required flag and reject programs with inlined
helpers when no JIT is available, where the interpreter would
otherwise jump into an invalid address (Tiezhu Yang)
- Fix the x86 JIT per-CPU address resolution into an extended
register where the REX prefix dropped the high destination register
bit (Vineet Gupta)
- Reject MEM_ALLOC BTF accesses past object bounds, arena frees below
the arena base, and mixed arena and ordinary atomic paths (Yiyang
Chen)
- Fix the trampoline handling of 128-bit arguments and of return
values larger than 8 bytes (Yonghong Song)
- Ensure that any fault prone load is rewritten with exception table
handling, and fix the arena load-acquire and atomic fetch handling
in the x86, arm64, riscv and s390 JITs (Daniel Borkmann)
- Many more fixes and cleanups across the verifier, arena,
trampolines, sockmap, cgroup, ring buffer, x86/arm64/riscv/s390
JITs, libbpf, bpftool, resolve_btfids and selftests"
* tag 'bpf-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (373 commits)
selftests/bpf: Add tests for a store on a fault prone qdisc pointer
selftests/bpf: Add tests for fault prone loads out of RCU pointers
selftests/bpf: Add tests for pointer type merge at a shared load
selftests/bpf: Remove duplicate copies of the arena spinlock qnodes
selftests/bpf: Retry stat generation in cgroup_iter_memcg
selftests/bpf: Test pseudo-function policy diagnostics
bpf: Distinguish function references in policy diagnostics
bpf: Preserve source attribution without source text
selftests/bpf: Test kfunc argument diagnostics
bpf: Correct kfunc argument diagnostics
bpf: Use canonical stack argument names in diagnostics
bpf: Preserve R0 lineage across helper calls
selftests/bpf: Exercise negative optlen in cgroup getsockopt hook
bpf: Reject negative optlen in cgroup getsockopt hook
selftests/bpf: tc_tunnel - validate decap GSO and encapsulation state
bpf: Clear decap state on skb_adjust_room shrink path
bpf: Allow new DECAP flags and add guard rails
bpf: Add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation
bpf: Refactor masks for ADJ_ROOM flags and encap validation
bpf: Name the enum for BPF_FUNC_skb_adjust_room flags
...
|
|
Pull HID updates from Jiri Kosina:
"Core:
- fix long-standing force-feedback initialization race across the
subsystem (Dmitry Torokhov)
- switch to system_dfl_wq (Marco Crivellari)
AMD-SFH:
- support for tablet-mode switch for AMD SFH-based systems (Basavaraj
Natikar)
HyperX:
- support for HyperX QuadCast 2 (Benjamin Blume)
I2C-HID:
- support for devices that provide HID descriptor solely through
the ACPI _DSM method (XIE Zhibang)
Intel-THC-HID:
- support for full I2C bus config parameters (Even Xu)
Logitech:
- HID++ 2.0 repogrammable button support (Elliot Douglas)
- Bolt receiver support for HID++ devices (Erik Håkansson)
MSI:
- support for MSI Claw (Derek J. Clark)
Steam:
- initial support for 2026 Steam Controller (Vicki Pfau)
- support for sensor events on the 2025 Steam Controller (Vicki Pfau)
And many, many other fixes for various long standing issues that were
found by new modern tools, and quite a few device ID additions"
* tag 'hid-for-linus-2026081901' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (146 commits)
HID: tmff: Use 64-bit arithmetic for force feedback scaling
HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMU
HID: sensor: custom: Fix field sysfs group cleanup on failure
HID: sensor: custom: Fix use-after-free in enable_sensor
HID: intel-thc-hid: intel-quickspi: bound GET_REPORT response to the caller buffer
HID: haptic: don't write an uninitialized value to unhandled usages
HID: intel-thc-hid: intel-quickspi: fix autosuspend cleanup during teardown
HID: intel-thc-hid: intel-quicki2c: fix autosuspend cleanup during teardown
HID: steam: Zero out inputs when disabling gamepad mode
HID: steam: Clean up locking
HID: steam: Don't set feature reports when disconnecting
HID: steam: Fix wording of connect/disconnect logs
HID: steam: Initial 2026 Steam Controller support
HID: steam: Refactor registration
HID: logitech: add Bolt receiver support for Logitech HID++ devices
HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature
HID: universal-pidff: stop the device when force-feedback init fails
HID: haptic: move FF initialization into .input_configured()
HID: logitech-hidpp: move FF initialization to .input_configured()
HID: megaworld: move FF initialization to .input_configured()
...
|
|
- fix long-standing force-feedback initialization race across the subsystem
(Dmitry Torokhov)
- switch to system_dfl_wq (Marco Crivellari)
|
|
- support for tablet-mode switch for AMD SFH-based systems (Basavaraj Natikar)
|
|
- backlight fixes and improvements (Andre Eikmeyer)
|
|
- support for HyperX QuadCast 2 (Benjamin Blume)
|
|
- add support for devices that provide HID descriptor solely through ACPI _DSM
method (XIE Zhibang)
|
|
- support for full I2C bus config parameters (Even Xu)
|
|
- HID++ 2.0 repogrammable button support (Elliot Douglas)
- Bolt receiver support for HID++ devices (Erik Håkansson)
|
|
- support for MSI Claw (Derek J. Clark)
|
|
- assorted fixes (Alexandre Derumier, Christos Maragkos, Jiangshan Yi)
|
|
- memory management fix on device cleanup path (Xu Rao)
- profile index handling fix (Michael Bommarito)
|
|
- small fixes and code improvements (e.g. devm_kasprintf() conversion,
using guard() and scoped_guart(), etc) (Doruk Tan Ozturk,
Rosalie Wanders)
|
|
- initial support for 2026 Steam Controller (Vicki Pfau)
- support for sensor events on the 2025 Steam Controller (Vicki Pfau)
- assorted fixes, improvements and code refactoring (Vicki Pfau)
|
|
- support for MSI Raider A18 HX A9WJG RGB (David Glushkov)
- Improvements and fixes for various Arctis devices support (Sriman Achanta)
|
|
- report data handling optimization (Ruoyu Wang)
|
|
The logical minimum and maximum values come from the HID report
descriptor and cover the full signed 32-bit range. Subtracting them in
an int can overflow before the force feedback value is scaled. The
subsequent multiplication can overflow as well, producing an incorrect
value despite the final range checks.
Use 64-bit intermediates for both scaling helpers, as done by commit
48d1677779ad ("HID: pidff: Fix integer overflow in pidff_rescale") for
the same arithmetic in the PID driver. This keeps the arithmetic
defined for the complete descriptor range before the result is clamped.
Fixes: dc76c912145f ("Input: use new FF interface in the HID force feedback drivers")
Fixes: b27c9590ca0f ("HID: add support for Thrustmaster FGT Force Feedback wheel")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
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 <jkosina@suse.com>
|
|
hid_sensor_custom_add_attributes() creates one sysfs group for each
custom sensor field. If sysfs_create_group() fails after some groups
have already been created, the function returns the error without
removing the previously created groups.
Add a local unwind path to remove the groups that were already created.
With enable_sensor exposed only after the field attributes are ready,
this path can free sensor_inst->fields without leaving enable_sensor
able to access pointers into that array.
Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
enable_sensor_store() can call set_power_report_state(), which
dereferences sensor_inst->power_state and sensor_inst->report_state.
These pointers refer to entries in sensor_inst->fields.
Create the field attributes before exposing the enable_sensor sysfs
attribute, so enable_sensor cannot be accessed before the state it
depends on has been initialized.
On remove, delete enable_sensor before freeing the field attributes,
so a concurrent sysfs write cannot dereference freed memory through
power_state or report_state.
Reported-by: Sashiko AI Review <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260623021950.1736413-1-haoxiang_li2024@163.com?part=1
Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
quickspi_hid_raw_request() receives the caller's buffer length in len, but
quickspi_get_report() never sees it and copies the whole device-supplied
response into buf regardless:
memcpy(buf, qsdev->report_buf, qsdev->report_len);
qsdev->report_len comes from the input report the touch controller returns,
while buf is sized to whatever the caller asked hidraw for through
HIDIOCGFEATURE or HIDIOCGINPUT. A response larger than that overflows buf
with device-controlled content.
The intel-quicki2c sibling already passes the caller length down to
quicki2c_get_report() and validates the response against it before the
copy. Do the same here.
Fixes: 4138f21115ae ("HID: intel-thc-hid: intel-quickspi: Complete THC QuickSPI driver")
Suggested-by: Sashiko AI <sashiko-bot@kernel.org>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Even Xu <even.xu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
Linus Torvalds
Benjamin Tissoires
Slawomir Stepien
Oscar Priego Verdugo
Berke Durak
Stuart Hayhurst
Youth Cao
Tristan Madani
Oleg Keri
Dmitry Antipov
Erik Håkansson
Andres Diaz
Chen Changcheng
René Onier
Lovekesh Solanki
Wei Jie LAW
Junjie Cao
Kees Cook
Shen Yongchao
Ibrahim Hashimov
Dave Carey
Vadim Klishko
Jiri Kosina
Jiri Kosina
Linmao Li
Xianglin Lin
Haoxiang Li
HyeongJun An