linux-next.git/drivers/hid, branch master

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git

2026-09-04T17:21:33+00:00

HID: bpf: serialize device reference release in struct_ops destroy path

2026-09-01T16:49:26+00:00

__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 Assisted-by: Hermes:kimi-k3 Signed-off-by: Benjamin Tissoires

HID: rmi: fix OOB access with undersized RMI reports

2026-09-01T15:06:17+00:00

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

HID: bpf: mark struct hid_device as safe BPF pointer

2026-09-01T14:08:28+00:00

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 Signed-off-by: Benjamin Tissoires

HID: wacom: validate report length in wacom_intuos_pro2_bt_irq

2026-08-25T12:09:34+00:00

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 Assisted-by: AuditCode-AI:2026.07 Acked-by: Jason Gerecke Signed-off-by: Jiri Kosina

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

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

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

HID: i2c-hid: Add a quirk for a Cirque I2C device.

2026-08-25T08:49:04+00:00

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 Signed-off-by: Benjamin Tissoires

Merge tag 'platform-drivers-x86-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

2026-08-24T17:16:35+00:00

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 ...

HID: hyperv: make pointer arithmetics understandable for FORTIFY_SOURCE

2026-08-21T13:59:01+00:00

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ß Tested-by: Jürgen Groß Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

HID: hyperv: fix build breakage with certain configs

2026-08-21T13:31:51+00:00

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 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 Signed-off-by: Jiri Kosina