* Re: [PATCH v1] Input: Drop unused assignments from pnp_device_id arrays
From: Dmitry Torokhov @ 2026-06-10 16:57 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Kees Cook, Werner Sembach, Christoffer Sandberg, feng, gongqi,
linux-input, linux-kernel
In-Reply-To: <ailQutR_TfyCQ-SP@monoceros>
On Wed, Jun 10, 2026 at 01:58:17PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello Dmitry,
>
> On Tue, Jun 09, 2026 at 11:12:49PM -0700, Dmitry Torokhov wrote:
> > On Tue, Jun 09, 2026 at 04:53:25PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > 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>
> > > ---
> > > drivers/input/gameport/ns558.c | 46 +++++++++++-----------
> > > drivers/input/serio/i8042-acpipnpio.h | 56 +++++++++++++--------------
> > > 2 files changed, 51 insertions(+), 51 deletions(-)
> > >
> > > diff --git a/drivers/input/gameport/ns558.c b/drivers/input/gameport/ns558.c
> > > index fdece6ec1df3..f70a96c4f1fd 100644
> > > --- a/drivers/input/gameport/ns558.c
> > > +++ b/drivers/input/gameport/ns558.c
> > > @@ -148,29 +148,29 @@ static int ns558_isa_probe(int io)
> > > #ifdef CONFIG_PNP
> > >
> > > static const struct pnp_device_id pnp_devids[] = {
> > > - [...]
> > > - { .id = "", },
> > > + [...]
> > > + { }
> >
> > This goes BOOOM! You have to keep empty .id string as terminator.
>
> How so? Given that my patch doesn't modify the resulting ns558.o I doubt
> that. If .id was a char *, I'd agree, but it's a char[], so there should
> be no difference (and the compiler agrees).
Sorry, brain fart on my part.
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads
From: Jiri Kosina @ 2026-06-10 16:41 UTC (permalink / raw)
To: Zhang Lixu
Cc: Jonathan Cameron, Srinivas Pandruvada, Benjamin Tissoires,
David Lechner, Nuno Sá, Andy Shevchenko, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260610082911.157232-2-lixu.zhang@intel.com>
On Wed, 10 Jun 2026, Zhang Lixu wrote:
> From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>
> sensor_hub_input_attr_get_raw_value() is limited to returning a single
> 32-bit value, which is insufficient for sensors that report data larger
> than 32 bits, such as a quaternion with four s16 elements.
>
> Add sensor_hub_input_attr_read_values() that accepts a caller-provided
> buffer and accumulates incoming data until the buffer is full. The two
> paths are distinguished in sensor_hub_raw_event() by pending.max_raw_size
> being non-zero, preserving backward compatibility.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Co-developed-by: Zhang Lixu <lixu.zhang@intel.com>
> Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Jiri Kosina <jkosina@suse.com>
Jonathan, will you take the whole lot through your tree?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: hid-goodix-spi: validate report size to prevent stack buffer overflow
From: Jiri Kosina @ 2026-06-10 16:35 UTC (permalink / raw)
To: Tianchu Chen; +Cc: bentiss, linux-input, linux-kernel, stable
In-Reply-To: <f7e444a3facbe5fb2627167ab205771476e46bc8@linux.dev>
On Fri, 29 May 2026, Tianchu Chen wrote:
> From: Tianchu Chen <flynnnchen@tencent.com>
>
> goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack
> buffer (tmp_buf), writing an 11-12 byte header followed by the
> caller-supplied report data. The HID core caps report size at
> HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set
> hid_ll_driver.max_buffer_size and performs no bounds checking before
> copying the payload:
>
> memcpy(tmp_buf + tx_len, buf, len);
>
> A hidraw SET_REPORT ioctl with a report larger than ~116 bytes
> overflows the stack buffer.
>
> Add a size check after constructing the header, rejecting reports that
> would exceed the buffer capacity.
>
> Discovered by Atuin - Automated Vulnerability Discovery Engine.
>
> Fixes: 75e16c8ce283 ("HID: hid-goodix: Add Goodix HID-over-SPI driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
Applied, thanks and sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 7/8] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Conor Dooley @ 2026-06-10 16:34 UTC (permalink / raw)
To: Jun Yan
Cc: conor+dt, devicetree, dmitry.torokhov, krzk+dt, linux-input,
linux-kernel, robh
In-Reply-To: <20260610133458.970174-1-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
On Wed, Jun 10, 2026 at 09:34:58PM +0800, Jun Yan wrote:
> > > > > + threshold, so counts differ.
> > > > > =3D20
> > > > > microchip,calib-sensitivity:
> > > > > $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > > @@ -149,7 +153,7 @@ patternProperties:
> > > > > reg:
> > > > > description: LED channel number
> > > > > minimum: 0
> > > > > - maximum: 7
> > > > > + maximum: 10
> > > > > =3D20
> > > > > required:
> > > > > - reg
> > > > > @@ -199,6 +203,19 @@ allOf:
> > > > > reg:
> > > > > maximum: 1
> > > > > =3D20
> > > > > + - if:
> > > > > + properties:
> > > > > + compatible:
> > > > > + contains:
> > > > > + enum:
> > > > > + - microchip,cap1188
> > > >=20
> > > > I don't understand this restriction, shouldn't this be
> > > > if: properties: compatible: not: contains: microchip,cap1114
> > > > so that the constraints before your change are retained?
> > > >=20
> > >=20
> > > Previously, the LED reg property had a default maximum of 7 for CAP1188.=
> > =20
> > > With the addition of CAP1114, the default maximum is now 11.=20
> > > An if-then constraint is added to limit the LED count for CAP1188.
> >
> > Ah, is this because cap1188 is the only existing device in the binding
> > that actually has LEDs?
>
> - CAP1126: max 2 LED channels (0-1)
> - CAP1188: max 8 LED channels (0-7)
> - CAP1106, CAP12xx: no LED support
>
> The LED reg property constraints for CAP1126 were added in Patch 3 [1].
>
> [1] https://lore.kernel.org/linux-input/20260606150458.250606-4-jerrysteve1101@gmail.com/
Okay, that makes more sense now. Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk
From: Jiri Kosina @ 2026-06-10 16:33 UTC (permalink / raw)
To: Helge Bahmann
Cc: Nehal Bakulchandra Shah, Sandeep Singh, Basavaraj Natikar,
Benjamin Tissoires, linux-hid, linux-input
In-Reply-To: <6879487.lOV4Wx5bFT@lothlorien>
On Mon, 27 Apr 2026, Helge Bahmann wrote:
> Add an input driver that interprets the "operation mode" sensor offered
> by the amd sfh on some laptop models.
>
> Add a quirk to make the driver work again with the Asus VivoBook
> VivoBook (turn off the "disable interrupts" flag).
>
> Expose the intr_disable flag as a module parameter in case it turns out
> to be needed on further laptop models.
>
> Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
Basavaraj, could you please review this one? Thanks.
> ---
> drivers/hid/amd-sfh-hid/amd_sfh_client.c | 25 ++++++++------
> drivers/hid/amd-sfh-hid/amd_sfh_hid.c | 43 ++++++++++++++++++++++++
> drivers/hid/amd-sfh-hid/amd_sfh_hid.h | 6 ++++
> drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 9 +++++
> drivers/hid/amd-sfh-hid/amd_sfh_pcie.h | 3 ++
> 5 files changed, 75 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> index 7017bfa59093..a24757c5a203 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> @@ -128,10 +128,16 @@ void amd_sfh_work_buffer(struct work_struct *work)
> guard(mutex)(&mp2->lock);
> for (i = 0; i < cli_data->num_hid_devices; i++) {
> if (cli_data->sensor_sts[i] == SENSOR_ENABLED) {
> - report_size = mp2->mp2_ops->get_in_rep(i, cli_data->sensor_idx[i],
> - cli_data->report_id[i], in_data);
> - hid_input_report(cli_data->hid_sensor_hubs[i], HID_INPUT_REPORT,
> - in_data->input_report[i], report_size, 0);
> + if (cli_data->hid_sensor_hubs[i]) {
> + report_size = mp2->mp2_ops->get_in_rep(i, cli_data->sensor_idx[i],
> + cli_data->report_id[i],
> + in_data);
> + hid_input_report(cli_data->hid_sensor_hubs[i], HID_INPUT_REPORT,
> + in_data->input_report[i], report_size, 0);
> + } else if (cli_data->sensor_idx[i] == op_idx &&
> + cli_data->modeswitch_input) {
> + amdtp_modeswitch_report(i, cli_data->modeswitch_input, in_data);
> + }
> }
> }
> schedule_delayed_work(&cli_data->work_buffer, msecs_to_jiffies(AMD_SFH_IDLE_LOOP));
> @@ -327,15 +333,12 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
>
> for (i = 0; i < cl_data->num_hid_devices; i++) {
> cl_data->cur_hid_dev = i;
> - if (cl_data->sensor_idx[i] == op_idx) {
> - dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
> - cl_data->sensor_idx[i], get_sensor_name(cl_data->sensor_idx[i]),
> - cl_data->sensor_sts[i]);
> - continue;
> - }
>
> if (cl_data->sensor_sts[i] == SENSOR_ENABLED) {
> - rc = amdtp_hid_probe(i, cl_data);
> + if (cl_data->sensor_idx[i] != op_idx)
> + rc = amdtp_hid_probe(i, cl_data);
> + else
> + rc = amdtp_modeswitch_probe(i, cl_data);
> if (rc)
> goto cleanup;
> } else {
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_hid.c b/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> index 81f3024b7b1b..44008c02b63c 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> @@ -181,4 +181,47 @@ void amdtp_hid_remove(struct amdtp_cl_data *cli_data)
> cli_data->hid_sensor_hubs[i] = NULL;
> }
> }
> +
> + /* note: cli_data->modeswitch_input implicitly cleaned by devres */
> +}
> +
> +int amdtp_modeswitch_probe(u32 cur_hid_dev, struct amdtp_cl_data *cli_data)
> +{
> + struct amd_mp2_dev *mp2 = container_of(cli_data->in_data, struct amd_mp2_dev, in_data);
> + struct device *dev = &mp2->pdev->dev;
> + struct input_dev *input;
> + int rc;
> +
> + input = devm_input_allocate_device(dev);
> + if (IS_ERR(input))
> + return PTR_ERR(input);
> +
> + input->name = "AMD SFH tablet mode switch sensor";
> + input->id.bustype = BUS_PCI;
> +
> + input_set_capability(input, EV_SW, SW_TABLET_MODE);
> +
> + rc = input_register_device(input);
> + if (rc)
> + goto cleanup;
> +
> + cli_data->modeswitch_input = input;
> +
> + return 0;
> +
> +cleanup:
> + return rc;
> +}
> +
> +void amdtp_modeswitch_report(u32 index, struct input_dev *input, struct amd_input_data *in_data)
> +{
> + u32 *sensor_virt_addr = in_data->sensor_virt_addr[index];
> + u32 value = sensor_virt_addr[0];
> +
> + if (value == AMD_SFH_OP_IDX_MODE_TABLET)
> + input_report_switch(input, SW_TABLET_MODE, 1);
> + else
> + input_report_switch(input, SW_TABLET_MODE, 0);
> +
> + input_sync(input);
> }
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> index 7452b0302953..20aff7b75fbd 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> @@ -11,6 +11,8 @@
> #ifndef AMDSFH_HID_H
> #define AMDSFH_HID_H
>
> +#include <linux/input.h>
> +
> #define MAX_HID_DEVICES 7
> #define AMD_SFH_HID_VENDOR 0x1022
> #define AMD_SFH_HID_PRODUCT 0x0001
> @@ -50,6 +52,7 @@ struct amdtp_cl_data {
> u8 sensor_idx[MAX_HID_DEVICES];
> u8 *feature_report[MAX_HID_DEVICES];
> u8 request_done[MAX_HID_DEVICES];
> + struct input_dev *modeswitch_input;
> struct amd_input_data *in_data;
> struct delayed_work work;
> struct delayed_work work_buffer;
> @@ -78,4 +81,7 @@ void amdtp_hid_remove(struct amdtp_cl_data *cli_data);
> int amd_sfh_get_report(struct hid_device *hid, int report_id, int report_type);
> void amd_sfh_set_report(struct hid_device *hid, int report_id, int report_type);
> void amdtp_hid_wakeup(struct hid_device *hid);
> +int amdtp_modeswitch_probe(u32 cur_hid_dev, struct amdtp_cl_data *cli_data);
> +void amdtp_modeswitch_report(u32 index, struct input_dev *input, struct amd_input_data *in_data);
> +
> #endif
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> index 1d9f955573aa..cd9cff75f114 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> @@ -39,6 +39,8 @@ module_param_named(sensor_mask, sensor_mask_override, int, 0444);
> MODULE_PARM_DESC(sensor_mask, "override the detected sensors mask");
>
> static bool intr_disable = true;
> +module_param_named(intr_disable, intr_disable, bool, 0444);
> +MODULE_PARM_DESC(intr_disable, "override the interrupt disable sensor bit");
>
> static int amd_sfh_wait_response_v2(struct amd_mp2_dev *mp2, u8 sid, u32 sensor_sts)
> {
> @@ -317,6 +319,13 @@ static const struct dmi_system_id dmi_sfh_table[] = {
> DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook x360 435 G7"),
> },
> },
> + {
> + .callback = mp2_disable_intr,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "VivoBook_ASUSLaptop TP420UA_TM420UA"),
> + }
> + },
> {}
> };
>
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> index 2eb61f4e8434..5e968894ebe4 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> @@ -83,6 +83,9 @@ enum sensor_idx {
> als_idx = 19
> };
>
> +#define AMD_SFH_OP_IDX_MODE_LAPTOP 1
> +#define AMD_SFH_OP_IDX_MODE_TABLET 3
> +
> enum mem_use_type {
> USE_DRAM,
> USE_C2P_REG,
> --
> 2.47.3
>
>
>
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: nintendo: add support for HORI Wireless Switch Pad
From: Jiri Kosina @ 2026-06-10 16:32 UTC (permalink / raw)
To: Hector Zelaya
Cc: Benjamin Tissoires, Daniel J. Ogorchock, linux-input,
linux-kernel, Joshua Peisach
In-Reply-To: <20260527-hori-support-v2-1-195c2f832112@hectorzelaya.dev>
On Wed, 27 May 2026, Hector Zelaya wrote:
> Add support for the HORI Wireless Switch Pad (vendor 0x0f0d, product
> 0x00f6), a licensed third-party Nintendo Switch Pro Controller.
>
> The controller reports controller type 0x06 (vs 0x03 for first-party
> Pro Controllers) and has the following quirks:
>
> - SPI flash calibration data is incompatible; use default stick
> calibration values instead.
> - X and Y button bits are swapped compared to first-party controllers;
> add a dedicated button mapping table.
> - Rumble and IMU enable may timeout (no vibration motor in hardware);
> treat as non-fatal for licensed controllers.
>
> Tested over Bluetooth on NixOS with kernel 7.0.5 and 7.0.10:
> - All 14 buttons map correctly
> - Player LED sets on connect
> - Sticks report correctly with default calibration
> - IMU/gyro data streams at 60Hz
> - D-pad reports on ABS_HAT0X/HAT0Y
>
> Device information:
> Bluetooth name: Lic Pro Controller
> Bluetooth HID: 0005:0F0D:00F6
>
> Assisted-by: Kiro:Auto [Amazon Kiro IDE]
> Signed-off-by: Hector Zelaya <hector@hectorzelaya.dev>
> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost contacts
From: Jiri Kosina @ 2026-06-10 16:28 UTC (permalink / raw)
To: Dave Carey; +Cc: linux-input, Benjamin Tissoires
In-Reply-To: <CALPvRORBFHpbos=_xpBVchK-oSZF9EnY6n5-sAQGr=qiL13FbQ@mail.gmail.com>
On Thu, 14 May 2026, Dave Carey wrote:
> The INGENIC 17EF:6161 firmware on the Lenovo Yoga Book 9 14IAH10
> does not clear stale contact slots when fingers are lifted. Each
> HID report contains up to 10 finger slots, but only the first
> ContactCount slots represent valid contacts; the remaining slots
> retain TipSwitch=1 with positions from previous touches.
>
> Raw HID capture confirms this: across a 60-second capture with
> repeated multi-finger gestures, 90% of frames had more TipSwitch=1
> slots than the reported ContactCount. The ContactCount field itself
> is always accurate.
>
> Add MT_QUIRK_CONTACT_CNT_ACCURATE to the MT_CLS_YOGABOOK9I class so
> the driver stops processing slots once ContactCount valid contacts
> have been consumed, discarding the stale ghost entries per HID
> specification section 17. MT_QUIRK_NOT_SEEN_MEANS_UP (already in
> the class) ensures that any slot skipped by this guard is released
> via INPUT_MT_DROP_UNUSED at frame sync.
>
> Signed-off-by: Dave Carey <carvsdriver@gmail.com>
> Tested-by: Dave Carey <carvsdriver@gmail.com>
> ---
> This follows commit 108ac841 ("HID: multitouch: Fix Yoga Book 9 14IAH10
> touchscreen misclassification"), applied to hid/for-next on 2026-05-12,
> which established MT_CLS_YOGABOOK9I and added MT_QUIRK_NOT_SEEN_MEANS_UP.
>
> That fix made the touchscreens fully functional. With three or more
> fingers and repeated on/off gestures, ghost contacts then began appearing
> because the firmware leaves stale TipSwitch=1 data in slots beyond
> ContactCount. The capture showed patterns like cc=1 with 7 active slots,
> or cc=3 with 8 active slots, consistently across all gesture cycles.
> ContactCount was always the correct count. Verified ghost-free after this
> change across 6+ repeated three-finger swipe sequences.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: magicmouse: add haptic click configuration for Magic Trackpad 2
From: Jiri Kosina @ 2026-06-10 16:26 UTC (permalink / raw)
To: Christian Fressl; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260514171524.110189-1-christian@fressl.at>
On Thu, 14 May 2026, Christian Fressl wrote:
> Apple Magic Trackpad 2 devices support persistent haptic feedback
> configuration through feature reports 0x22 and 0x23. Add an opt-in
> module parameter to select either the verified silent-low profile or to
> disable haptic feedback.
>
> The default remains unchanged. The report payload format is
> reverse-engineered, so keep the existing payload bytes fixed and vary
> only the known 24-bit feedback value.
>
> The USB-C Trackpad exposes multiple HID interfaces. Use the one-shot
> actuator output report 0x53 only to identify the interface that accepts
> the persistent configuration reports; do not use it for the persistent
> setting itself.
>
> Tested on Apple Magic Trackpad USB-C 05ac:0324 with Ubuntu
> 6.17.0-23-generic. Compile-tested against HID for-next.
>
> Protocol information was derived from public reverse-engineering notes,
> then independently tested with local hardware.
>
> Link: https://github.com/mwyborski/Linux-Magic-Trackpad-2-Driver/issues/28#issuecomment-451625504
> Signed-off-by: Christian Fressl <christian@fressl.at>
> ---
> Changes in v2:
> - Cache haptic_click with READ_ONCE() before applying the setting.
[ ... snip ... ]
> +static int magicmouse_apply_haptic_click(struct hid_device *hdev)
> +{
> + unsigned int click = READ_ONCE(haptic_click);
Can you please elaborate on why the READ_ONCE() is needed specifically
here? I don't get it.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v5 0/3] HID: nintendo: Add preliminary Switch 2 controller driver
From: Jiri Kosina @ 2026-06-10 16:18 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Dmitry Torokhov, Benjamin Tissoires, linux-input
In-Reply-To: <20260512200051.2534081-1-vi@endrift.com>
On Tue, 12 May 2026, Vicki Pfau wrote:
> This series adds preliminary support for Switch 2 controllers using the
> same split-driver model as previous versions. This is a minor iteration on
> v4, fixing some leaked input_dev objects in error paths as well as fixing a
> merge/rebase error when CONFIG_PM ifdefs got removed in 7.0.
>
> Vicki Pfau (3):
> HID: nintendo: Add preliminary Switch 2 controller driver
> HID: nintendo: Add rumble support for Switch 2 controllers
> HID: nintendo: Add unified report format support
>
> MAINTAINERS | 1 +
> drivers/hid/Kconfig | 19 +-
> drivers/hid/hid-ids.h | 4 +
> drivers/hid/hid-nintendo.c | 1504 ++++++++++++++++-
> drivers/hid/hid-nintendo.h | 72 +
> drivers/input/joystick/Kconfig | 11 +
> drivers/input/joystick/Makefile | 1 +
> drivers/input/joystick/nintendo-switch2-usb.c | 353 ++++
> 8 files changed, 1951 insertions(+), 14 deletions(-)
> create mode 100644 drivers/hid/hid-nintendo.h
> create mode 100644 drivers/input/joystick/nintendo-switch2-usb.c
Dmitry, do you have any review comments to the changes under
drivers/input/joystick, please?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: pidff: Use correct effect type in effect update
From: Jiri Kosina @ 2026-06-10 16:00 UTC (permalink / raw)
To: Oleg Makarenko
Cc: bentiss, stable, Oliver Roundtree, Ryno Kotzé,
Tomasz Pakuła, Anssi Hannula, Dmitry Torokhov, linux-input,
linux-usb, linux-kernel
In-Reply-To: <20260609160031.493353-1-oleg@makarenk.ooo>
On Tue, 9 Jun 2026, Oleg Makarenko wrote:
> When updating an existing effect, the effect type from the last created
> effect was sent to the device instead of the updated one.
> This caused incorrect reports when a game creates multiple different
> effects and updates only one that is not the last created.
>
> Fixes FFB in multiple games that create multiple simultaneous effects
> (Forza Horizon 5/6).
>
> Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices")
> Cc: <stable@vger.kernel.org>
> Tested-by: Oliver Roundtree <oroundtree1@gmail.com>
> Co-developed-by: Ryno Kotzé <lemon.xah@gmail.com>
> Signed-off-by: Ryno Kotzé <lemon.xah@gmail.com>
> Signed-off-by: Oleg Makarenko <oleg@makarenk.ooo>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 7/7] iio: pressure: hid-sensor-press: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:55 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-7-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Unsafe casting and blind dereferencing of `raw_data` causes unaligned memory accesses and Endianness data corruption.
- [High] Failure to reset the timestamp variable causes stale timestamps to be pushed continuously.
--
commit e758a7e12e760b133513494eca06c038aeaa377a
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: pressure: hid-sensor-press: use u32 instead of unsigned
This patch changes the usage_id parameter type from unsigned to u32 in
callback functions. This aligns the signature with the expected callback
API and improves code clarity without making functional changes.
> diff --git a/drivers/iio/pressure/hid-sensor-press.c b/drivers/iio/pressure/hid-sensor-press.c
> index a039b99d9851d..3e47a10d72a89 100644
> --- a/drivers/iio/pressure/hid-sensor-press.c
> +++ b/drivers/iio/pressure/hid-sensor-press.c
> @@ -155,7 +155,7 @@ static const struct iio_info press_info = {
>
> /* Callback handler to send event after all samples are received and captured */
> static int press_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> void *priv)
> {
> struct iio_dev *indio_dev = platform_get_drvdata(priv);
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing issue
with how the timestamp is handled in press_proc_event().
If the timestamp is zero, it gets populated with the current system time:
press_proc_event() {
...
if (atomic_read(&press_state->common_attributes.data_ready)) {
if (!press_state->timestamp)
press_state->timestamp = iio_get_time_ns(indio_dev);
iio_push_to_buffers_with_ts(indio_dev, &press_state->scan,
sizeof(press_state->scan),
press_state->timestamp);
}
...
}
However, the driver doesn't seem to reset press_state->timestamp back to zero
after pushing the buffer. Will this cause the first recorded software timestamp
to be continuously reused for all subsequent readings if the hardware does not
provide its own timestamp?
[ ... ]
> @@ -176,7 +176,7 @@ static int press_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int press_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is also a pre-existing issue, but while looking at press_capture_sample(),
could the direct cast of raw_data cause memory alignment or endianness problems?
press_capture_sample() {
...
switch (usage_id) {
case HID_USAGE_SENSOR_ATMOSPHERIC_PRESSURE:
press_state->scan.press_data = *(u32 *)raw_data;
ret = 0;
break;
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
press_state->timestamp = hid_sensor_convert_timestamp(
&press_state->common_attributes, *(s64 *)raw_data);
break;
...
}
Since raw_data points directly into the packed HID report buffer, which is
unaligned, does directly casting it to a u32 or s64 pointer violate C
alignment rules and risk kernel panics on architectures without unaligned
memory access support?
Additionally, since HID reports are little endian, wouldn't casting directly
on a big endian platform reverse the byte order? For example, if reading a
16-bit field on a big endian system, could this place the actual data into
the upper 16 bits of the u32, resulting in garbage data being sent to
userspace?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH 0/7] ASUS Zenbook Duo keyboard support
From: Jiri Kosina @ 2026-06-10 15:54 UTC (permalink / raw)
To: Paolo Pisati; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20260513163248.16483-1-p.pisati@gmail.com>
On Wed, 13 May 2026, Paolo Pisati wrote:
> Add support for the ASUS Zenbook Duo line of usb/BT wireless convertible keyboards.
>
> This patchset is a collective effort, gathered here:
>
> https://github.com/NeroReflex/asusctl/issues/25
Applied to hid.git#for-7.2/asus, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 5/7] iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:51 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-5-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unconditional pointer casts in `incl_3d_capture_sample` cause unaligned memory access, endianness mismatch, and out-of-bounds field reads.
--
commit ffa9a4c020f23415f0ba3c3eae4063a4d5e16403
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
This commit replaces the bare 'unsigned' type with 'u32' for the usage_id
variable in several callback handlers. This change aligns the code with the
expected callback API types and improves clarity. There are no functional
changes introduced by this patch.
> diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c b/drivers/iio/orientation/hid-sensor-incl-3d.c
> index 4e23a598a3fb9..c7fbff498be7a 100644
> --- a/drivers/iio/orientation/hid-sensor-incl-3d.c
> +++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
[ ... ]
> /* Capture samples in local storage */
> static int incl_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is a pre-existing issue, but while reviewing this signature update I
noticed a potential memory access problem.
Looking further down in incl_3d_capture_sample(), raw_data is directly cast
and dereferenced:
switch (usage_id) {
case HID_USAGE_SENSOR_ORIENT_TILT_X:
incl_state->scan.incl_val[CHANNEL_SCAN_INDEX_X] = *(u32 *)raw_data;
And for timestamps:
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
incl_state->timestamp =
hid_sensor_convert_timestamp(&incl_state->common_attributes,
*(s64 *)raw_data);
Can this direct pointer casting trigger unaligned memory access exceptions on
architectures that do not natively support them?
Additionally, since HID report data is explicitly little-endian, does casting
the byte stream to a native u32 or s64 pointer cause it to read reversed
bytes on big-endian architectures?
Finally, the callback does not appear to check the raw_len parameter. If the
HID field is 16-bit or a 32-bit timestamp, will the unconditional 32-bit or
64-bit dereference fetch adjacent HID fields or uninitialized buffer padding,
potentially corrupting the reported sensor value?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v2] HID: wacom: stop hardware after post-start probe failures
From: Jiri Kosina @ 2026-06-10 15:49 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Ping Cheng, Jason Gerecke, Benjamin Tissoires, linux-input,
linux-kernel, stable, Ijae Kim, Dmitry Torokhov
In-Reply-To: <20260604045710.25512-1-mhun512@gmail.com>
On Thu, 4 Jun 2026, Myeonghun Pak wrote:
> wacom_parse_and_register() starts HID hardware before registering inputs
> and initializing pad LEDs/remotes. Those later steps can fail, but their
> error paths currently release Wacom resources without stopping the HID
> hardware.
>
> Route post-hid_hw_start() failures through hid_hw_stop() before
> releasing driver resources.
>
> This issue was identified during our ongoing static-analysis research while
> reviewing kernel code.
>
> Fixes: c1d6708bf0d3 ("HID: wacom: Do not register input devices until after hid_hw_start")
> Cc: stable@vger.kernel.org
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> Changes in v2:
> - Drop fail_quirks and use fail_hw_stop for every post-hid_hw_start()
> failure path, as suggested by Dmitry.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: wacom: fix NULL pointer dereference in wacom_intuos_pad()
From: Jiri Kosina @ 2026-06-10 15:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jinmo Yang, Ping Cheng, Jason Gerecke, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <ahoH87pet5BUQwfD@google.com>
On Fri, 29 May 2026, Dmitry Torokhov wrote:
> I think there are many more places in the driver where it used
> wacom->pad_input without verifying that it exists.
Absolutely correct observation, thanks :)
Jinmo, are you planning to submit extended version of the patch, please?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 4/7] iio: light: hid-sensor-prox: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:47 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-4-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unaligned and endian-dependent memory access from raw HID report buffer
--
commit 15de0e06ef54de0333e9e716c38314e57230ae3f
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: light: hid-sensor-prox: use u32 instead of unsigned
This commit changes the type of the usage_id parameter from unsigned to u32
in the callback functions of the HID sensor proximity driver. This matches
the expected API and improves code clarity, with no functional changes
intended.
> diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
> index edc9274a2c076..9059f00f0cedf 100644
> --- a/drivers/iio/light/hid-sensor-prox.c
> +++ b/drivers/iio/light/hid-sensor-prox.c
[ ... ]
> @@ -183,7 +183,7 @@ static int prox_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int prox_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is a pre-existing issue, but does this function safely access the raw
data from the HID report?
Since raw_data points into a packed HID report buffer, the data might not be
naturally aligned for 16-bit or 32-bit boundaries. It looks like we cast
directly to u16* and u32* later in this function:
drivers/iio/light/hid-sensor-prox.c:prox_capture_sample() {
...
case 2:
prox_state->human_presence[chan] = *(u16 *)raw_data * multiplier;
return 0;
case 4:
prox_state->human_presence[chan] = *(u32 *)raw_data * multiplier;
...
}
Could this trigger unaligned memory access faults on architectures that do
not support them in hardware?
Also, since HID reports encode data in little-endian format, would using the
host's native byte order here cause incorrect sensor readings on big-endian
architectures?
Would it be safer to use get_unaligned_le16() and get_unaligned_le32()
instead of direct casting?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 0/4] HID: wacom: add report length validation in irq handlers
From: Jiri Kosina @ 2026-06-10 15:47 UTC (permalink / raw)
To: Jinmo Yang
Cc: linux-input, benjamin.tissoires, linux-kernel, stable, Ping Cheng,
Jason Gerecke
In-Reply-To: <20260517135215.2220117-1-jinmo44.yang@gmail.com>
On Sun, 17 May 2026, Jinmo Yang wrote:
> Several wacom IRQ handler sub-functions access fixed offsets in the raw
> HID report buffer without validating the buffer length. wacom_wac_irq()
> receives the length from wacom_raw_event() but does not validate it
> before dispatching to the sub-functions, which do not receive the length
> parameter.
>
> A malicious USB device can declare a small HID report in its descriptor
> and send a matching short report that passes the HID core size check
> (csize >= rsize), but the driver assumes a full-size hardware report
> layout, leading to slab-out-of-bounds reads.
>
> Note: this is not mitigated by the recent HID core bounds checking
> series which validates actual_size >= declared_size. An attacker
> controls both the descriptor (declared size) and the sent data (actual
> size), so the core check passes. Driver-level validation against the
> expected hardware report layout is still necessary.
>
> Tested with KASAN on Linux 7.1-rc3 (slab-out-of-bounds confirmed) and
> verified kernel panic on a production device via uhid.
>
> Jinmo Yang (4):
> HID: wacom: validate report length for PL and PTU handlers
> HID: wacom: validate report length for DTU handler
> HID: wacom: validate report length for DTUS handler
> HID: wacom: validate report length for 24HDT and 27QHDT handlers
>
> drivers/hid/wacom_wac.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
CCing Ping and Jason for their review. Thanks in advance,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 6/7] iio: orientation: hid-sensor-rotation: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:47 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-6-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds read and unaligned access in `dev_rot_capture_sample`
- [High] Use-After-Free (UAF) race condition between device removal and raw event processing
--
commit de9f9c2c99851d2c61cb3fce183da2297778f18f
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: orientation: hid-sensor-rotation: use u32 instead of unsigned
Prefer 'u32' instead of bare 'unsigned' for usage_id variable.
This matches expected callback API type and improves code clarity.
No functional change.
> diff --git a/drivers/iio/orientation/hid-sensor-rotation.c b/drivers/iio/orientation/hid-sensor-rotation.c
> index 4a11e45550991..20563d8efaf6c 100644
> --- a/drivers/iio/orientation/hid-sensor-rotation.c
> +++ b/drivers/iio/orientation/hid-sensor-rotation.c
[ ... ]
> @@ -209,7 +209,7 @@ static int dev_rot_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int dev_rot_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This isn't a bug introduced by this patch, but does dev_rot_capture_sample()
blindly trust raw_len and raw_data derived from the HID device's report
descriptors?
If a malicious or faulty USB device provides a descriptor with a small report
size (e.g., 4 bytes), raw_len / 4 == sizeof(s16) evaluates to false. This
leads the code to execute:
memcpy(&rot_state->scan.sampled_vals, raw_data,
sizeof(rot_state->scan.sampled_vals));
Can this read out-of-bounds heap memory which is then pushed to IIO buffers
and leaked to userspace?
Furthermore, for HID_USAGE_SENSOR_TIME_TIMESTAMP, the code directly casts
and dereferences raw_data as a 64-bit integer:
rot_state->timestamp = hid_sensor_convert_timestamp(
&rot_state->common_attributes, *(s64 *)raw_data);
As HID reports are packed, raw_data can be unaligned. Could this cause a
kernel panic (unaligned access exception) on architectures with strict
alignment requirements?
[Severity: High]
This is also a pre-existing issue, but is there a use-after-free race
condition between device removal and raw event processing?
During removal, hid_dev_rot_remove() calls sensor_hub_remove_callback(),
which deletes the callback from the list using dyn_callback_lock but does
not synchronize with active or concurrent readers:
drivers/hid/hid-sensor-hub.c:sensor_hub_remove_callback() {
...
list_del(&callback->list);
kfree(callback);
...
}
Meanwhile, in sensor_hub_raw_event(), sensor_hub_get_callback() fetches the
callback pointer and drops the lock. The function then continues to invoke
callback->capture_sample() without any locks or reference counting:
drivers/hid/hid-sensor-hub.c:sensor_hub_raw_event() {
...
callback->capture_sample(hsdev, report->field[i]->logical, sz, ptr,
callback->pdev);
...
}
If device removal completes and devres frees indio_dev and dev_rot_state
before sensor_hub_raw_event() finishes execution on another CPU, will the
event handler dereference a freed function pointer or access the freed driver
state structure?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v2 3/7] iio: light: hid-sensor-als: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:47 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-3-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Directly casting the `raw_data` byte array to `u32*` and `s64*` in capture callbacks causes unaligned memory accesses, incorrect endianness handling, and potential out-of-bounds reads.
--
commit 8c6bb48eb0d753aea033d76922dc45a105550e60
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: light: hid-sensor-als: use u32 instead of unsigned
Prefer 'u32' instead of bare 'unsigned' for usage_id variable.
This matches expected callback API type and improves code clarity.
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index d72e260b82668..ae2fda8dc500a 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
[ ... ]
> @@ -263,7 +263,7 @@ static int als_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is a pre-existing issue, but does the direct cast in this function cause
unaligned memory accesses or endianness issues?
Just a few lines down in als_capture_sample(), raw_data is cast directly:
int ret = -EINVAL;
u32 sample_data = *(u32 *)raw_data;
The HID sensor hub core passes a byte pointer raw_data which points directly
into the raw HID report. In sensor_hub_report(), the pointer is incremented
by 1 to skip the report ID, making it immediately unaligned.
Dereferencing this unaligned pointer directly via *(u32 *) or *(s64 *) can
cause unaligned memory access faults on architectures that do not support
them.
Additionally, since HID reports are strictly little-endian, a direct
cast on a big-endian host might result in corrupted sensor data.
Should this code use get_unaligned_le32() and get_unaligned_le64() instead,
and also validate that raw_len is sufficient to prevent out-of-bounds reads?
The same direct cast pattern appears to be present in other HID sensors,
such as accel_3d_capture_sample() and gyro_3d_capture_sample().
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2 2/7] iio: accel: hid-sensor-accel-3d: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:46 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-2-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds read and unaligned access in capture_sample callbacks
--
commit 4cc56ddc040c8b55845a800e3ad9e90ea9d698c9
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: accel: hid-sensor-accel-3d: use u32 instead of unsigned
This patch changes the usage_id parameter type from unsigned to u32 in
hid-sensor-accel-3d callbacks to match the expected API type.
> diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
> index 2bf05ab5235ef..42c4259bf2094 100644
> --- a/drivers/iio/accel/hid-sensor-accel-3d.c
> +++ b/drivers/iio/accel/hid-sensor-accel-3d.c
[ ... ]
> @@ -247,7 +247,7 @@ static int accel_3d_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int accel_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is a pre-existing issue, but since we are looking at the signature of
accel_3d_capture_sample(), is there a risk of an out-of-bounds read or
unaligned access when dereferencing raw_data?
Further down in accel_3d_capture_sample(), raw_data is unconditionally
cast and dereferenced without verifying raw_len:
switch (usage_id) {
case HID_USAGE_SENSOR_ACCEL_X_AXIS:
case HID_USAGE_SENSOR_ACCEL_Y_AXIS:
case HID_USAGE_SENSOR_ACCEL_Z_AXIS:
offset = usage_id - HID_USAGE_SENSOR_ACCEL_X_AXIS;
accel_state->scan.accel_val[CHANNEL_SCAN_INDEX_X + offset] =
*(u32 *)raw_data;
ret = 0;
break;
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
accel_state->timestamp =
hid_sensor_convert_timestamp(
&accel_state->common_attributes,
*(int64_t *)raw_data);
Could a malicious or non-compliant HID device provide a report descriptor
with a smaller size (e.g., 1 byte) for these usages, causing the dereference
to read up to 7 bytes past the end of the allocated report buffer?
Also, since raw_data is a byte pointer originating from the HID core, could
casting it directly to u32* or int64_t* trigger an unaligned access exception
on architectures that do not support unaligned memory access?
Does this same pattern need to be addressed in gyro_3d_capture_sample()
within drivers/iio/gyro/hid-sensor-gyro-3d.c? It appears to perform the
same unconditional casts to u32* and s64* on raw_data.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2] HID: core: demote warning to debug level
From: Jiri Kosina @ 2026-06-10 15:44 UTC (permalink / raw)
To: Matteo Croce
Cc: Benjamin Tissoires, Lee Jones, linux-input, linux-kernel,
Matteo Croce
In-Reply-To: <20260523105545.68079-1-technoboy85@gmail.com>
On Sat, 23 May 2026, Matteo Croce wrote:
> From: Matteo Croce <teknoraver@meta.com>
>
> The log level for short messages was changed from debug to warning,
> flooding syslog on systems with devices that regularly send
> short reports, in my case an UPS:
>
> $ dmesg |grep -c 'Event data for report .* was too short'
> 35
>
> Demote it back to debug level.
>
> Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> Signed-off-by: Matteo Croce <teknoraver@meta.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] HID: lenovo: Add support for ThinkPad X13 Folio keyboard
From: Jiri Kosina @ 2026-06-10 15:39 UTC (permalink / raw)
To: Vishnu Sankar
Cc: bentiss, derekjohn.clark, mpearson-lenovo, vsankar, linux-input,
linux-kernel
In-Reply-To: <CABxCQKtr1g8xEg_EYEQhjsgAR7QtSQ0dDQhOAByuxvHBeHK5iA@mail.gmail.com>
On Wed, 10 Jun 2026, Vishnu Sankar wrote:
> Hi Jiri / Benjamin,
>
> Gently pinging on this series.
> Is there anything blocking acceptance or any changes needed from my side?
> The series has been tested on physical hardware.
Sorry for the delay. Now applied to hid.git#for-7.1/upstream-fixes.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v2 7/7] iio: pressure: hid-sensor-press: use u32 instead of unsigned
From: Sanjay Chitroda @ 2026-06-10 15:37 UTC (permalink / raw)
To: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: linux-input, linux-iio, linux-kernel, Sanjay Chitroda,
Maxwell Doose
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Prefer 'u32' instead of bare 'unsigned' for usage_id variable.
This matches expected callback API type and improves code clarity.
No functional change.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
---
drivers/iio/pressure/hid-sensor-press.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/pressure/hid-sensor-press.c b/drivers/iio/pressure/hid-sensor-press.c
index a039b99d9851..3e47a10d72a8 100644
--- a/drivers/iio/pressure/hid-sensor-press.c
+++ b/drivers/iio/pressure/hid-sensor-press.c
@@ -155,7 +155,7 @@ static const struct iio_info press_info = {
/* Callback handler to send event after all samples are received and captured */
static int press_proc_event(struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
void *priv)
{
struct iio_dev *indio_dev = platform_get_drvdata(priv);
@@ -176,7 +176,7 @@ static int press_proc_event(struct hid_sensor_hub_device *hsdev,
/* Capture samples in local storage */
static int press_capture_sample(struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
size_t raw_len, char *raw_data,
void *priv)
{
@@ -204,7 +204,7 @@ static int press_capture_sample(struct hid_sensor_hub_device *hsdev,
static int press_parse_report(struct platform_device *pdev,
struct hid_sensor_hub_device *hsdev,
struct iio_chan_spec *channels,
- unsigned usage_id,
+ u32 usage_id,
struct press_state *st)
{
int ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/7] iio: orientation: hid-sensor-rotation: use u32 instead of unsigned
From: Sanjay Chitroda @ 2026-06-10 15:37 UTC (permalink / raw)
To: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: linux-input, linux-iio, linux-kernel, Sanjay Chitroda,
Maxwell Doose
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Prefer 'u32' instead of bare 'unsigned' for usage_id variable.
This matches expected callback API type and improves code clarity.
No functional change.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
---
drivers/iio/orientation/hid-sensor-rotation.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/orientation/hid-sensor-rotation.c b/drivers/iio/orientation/hid-sensor-rotation.c
index 4a11e4555099..20563d8efaf6 100644
--- a/drivers/iio/orientation/hid-sensor-rotation.c
+++ b/drivers/iio/orientation/hid-sensor-rotation.c
@@ -176,7 +176,7 @@ static const struct iio_info dev_rot_info = {
/* Callback handler to send event after all samples are received and captured */
static int dev_rot_proc_event(struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
void *priv)
{
struct iio_dev *indio_dev = platform_get_drvdata(priv);
@@ -209,7 +209,7 @@ static int dev_rot_proc_event(struct hid_sensor_hub_device *hsdev,
/* Capture samples in local storage */
static int dev_rot_capture_sample(struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
size_t raw_len, char *raw_data,
void *priv)
{
@@ -240,7 +240,7 @@ static int dev_rot_capture_sample(struct hid_sensor_hub_device *hsdev,
/* Parse report which is specific to an usage id*/
static int dev_rot_parse_report(struct platform_device *pdev,
struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
struct dev_rot_state *st)
{
int ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/7] iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
From: Sanjay Chitroda @ 2026-06-10 15:37 UTC (permalink / raw)
To: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: linux-input, linux-iio, linux-kernel, Sanjay Chitroda,
Maxwell Doose
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Prefer 'u32' instead of bare 'unsigned' for usage_id variable.
This matches expected callback API type and improves code clarity.
No functional change.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
---
drivers/iio/orientation/hid-sensor-incl-3d.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c b/drivers/iio/orientation/hid-sensor-incl-3d.c
index 4e23a598a3fb..c7fbff498be7 100644
--- a/drivers/iio/orientation/hid-sensor-incl-3d.c
+++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
@@ -189,7 +189,7 @@ static const struct iio_info incl_3d_info = {
/* Callback handler to send event after all samples are received and captured */
static int incl_3d_proc_event(struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
void *priv)
{
struct iio_dev *indio_dev = platform_get_drvdata(priv);
@@ -212,7 +212,7 @@ static int incl_3d_proc_event(struct hid_sensor_hub_device *hsdev,
/* Capture samples in local storage */
static int incl_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
size_t raw_len, char *raw_data,
void *priv)
{
@@ -247,7 +247,7 @@ static int incl_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
static int incl_3d_parse_report(struct platform_device *pdev,
struct hid_sensor_hub_device *hsdev,
struct iio_chan_spec *channels,
- unsigned usage_id,
+ u32 usage_id,
struct incl_3d_state *st)
{
int ret;
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox