* 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
* [PATCH v2 4/7] iio: light: hid-sensor-prox: 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/light/hid-sensor-prox.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
index edc9274a2c07..9059f00f0ced 100644
--- a/drivers/iio/light/hid-sensor-prox.c
+++ b/drivers/iio/light/hid-sensor-prox.c
@@ -166,7 +166,7 @@ static const struct iio_info prox_info = {
/* Callback handler to send event after all samples are received and captured */
static int prox_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);
@@ -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)
{
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/7] iio: light: hid-sensor-als: 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/light/hid-sensor-als.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index d72e260b8266..ae2fda8dc500 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -241,7 +241,7 @@ static const struct iio_info als_info = {
/* Callback handler to send event after all samples are received and captured */
static int als_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);
@@ -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)
{
@@ -305,7 +305,7 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
/* Parse report which is specific to an usage id*/
static int als_parse_report(struct platform_device *pdev,
struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
struct als_state *st)
{
struct iio_chan_spec *channels;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/7] iio: accel: hid-sensor-accel-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/accel/hid-sensor-accel-3d.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
index 2bf05ab5235e..42c4259bf209 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -223,7 +223,7 @@ static void hid_sensor_push_data(struct iio_dev *indio_dev, void *data,
/* Callback handler to send event after all samples are received and captured */
static int accel_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);
@@ -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)
{
@@ -283,7 +283,7 @@ static int accel_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
static int accel_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 accel_3d_state *st)
{
int ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/7] iio: gyro: hid-sensor-gyro-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/gyro/hid-sensor-gyro-3d.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index e48c25c87b6d..bbca2111e79b 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -177,7 +177,7 @@ static const struct iio_info gyro_3d_info = {
/* Callback handler to send event after all samples are received and captured */
static int gyro_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);
@@ -199,7 +199,7 @@ static int gyro_3d_proc_event(struct hid_sensor_hub_device *hsdev,
/* Capture samples in local storage */
static int gyro_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
- unsigned usage_id,
+ u32 usage_id,
size_t raw_len, char *raw_data,
void *priv)
{
@@ -234,7 +234,7 @@ static int gyro_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
static int gyro_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 gyro_3d_state *st)
{
int ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/7] HID: iio: basic clean up for usage_id
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
Hi all,
This series updates all HID IIO drivers to use 'u32' instead of
bare 'unsigned' for the usage_id parameter.
This matches expected callback API type and improves code clarity,
as HID usage IDs are defined as 32-bit values.
No functional changes are introduced.
Testing:
- Compiled with W=1 for each patch in the series
---
Changes in v2:
- rectify commit message with input from Jonathan
- added reviewed by tag in all change of series
- Link to v1: https://patch.msgid.link/20260606-6-june-hid-iio-correct-usage-id-v1-0-dd4a6820b674@gmail.com
---
Sanjay Chitroda (7):
iio: gyro: hid-sensor-gyro-3d: use u32 instead of unsigned
iio: accel: hid-sensor-accel-3d: use u32 instead of unsigned
iio: light: hid-sensor-als: use u32 instead of unsigned
iio: light: hid-sensor-prox: use u32 instead of unsigned
iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
iio: orientation: hid-sensor-rotation: use u32 instead of unsigned
iio: pressure: hid-sensor-press: use u32 instead of unsigned
drivers/iio/accel/hid-sensor-accel-3d.c | 6 +++---
drivers/iio/gyro/hid-sensor-gyro-3d.c | 6 +++---
drivers/iio/light/hid-sensor-als.c | 6 +++---
drivers/iio/light/hid-sensor-prox.c | 4 ++--
drivers/iio/orientation/hid-sensor-incl-3d.c | 6 +++---
drivers/iio/orientation/hid-sensor-rotation.c | 6 +++---
drivers/iio/pressure/hid-sensor-press.c | 6 +++---
7 files changed, 20 insertions(+), 20 deletions(-)
---
base-commit: ae696dfa47c30016cd429b9db5e70b259b8f509e
change-id: 20260606-6-june-hid-iio-correct-usage-id-57ce92cb102b
Best regards,
--
Sanjay Chitroda <sanjayembeddedse@gmail.com>
^ permalink raw reply
* Re: [PATCH v14 0/2] Firmware Support for USB-HID Devices and CP2112
From: Jiri Kosina @ 2026-06-10 15:35 UTC (permalink / raw)
To: Danny Kaehn
Cc: Benjamin Tissoires, Andy Shevchenko, Andi Shyti, Conor Dooley,
linux-input, Dmitry Torokhov, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen,
Bartosz Golaszewski
In-Reply-To: <20260520-cp2112-dt-v14-0-b1b4b6734b6f@plexus.com>
On Wed, 20 May 2026, Danny Kaehn wrote:
> This patchset allows USB-HID devices to have Firmware bindings through sharing
> the USB fwnode with the HID driver, and adds such a binding and driver
> implementation for the CP2112 USB to SMBus Bridge (which necessitated the
> USB-HID change). This change allows a CP2112 permanently attached in hardware to
> be described in DT and ACPI and interoperate with other drivers.
Applied to hid.git#for-7.2/cp2112, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 11/12] HID: hid-core: sanitize user input in 'new_id_store'
From: sashiko-bot @ 2026-06-10 15:32 UTC (permalink / raw)
Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-mod-devicetable-hid_device_id-v2-11-a1d7473ccd9c@thegoodpenguin.co.uk>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Restricting `driver_data` to strictly match an existing `id_table` entry breaks backward compatibility and defeats the purpose of the `new_id` interface.
--
commit 613c086c5db811baec4d7b28a4e3757a62048b24
Author: Pawel Zalewski (The Capable Hub) <pzalewski@thegoodpenguin.co.uk>
Subject: HID: hid-core: sanitize user input in 'new_id_store'
This commit modifies the new_id sysfs interface for HID drivers. It adds a
check to ensure that any provided driver_data value strictly matches an
existing entry within the driver's id_table, preventing arbitrary values
from being passed.
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 41a79e43c82b3..e060e5ec4ea62 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2647,6 +2647,8 @@ static ssize_t new_id_store(struct device_driver *drv, const char *buf,
> size_t count)
> {
> struct hid_driver *hdrv = to_hid_driver(drv);
> + const struct hid_device_id *ids = hdrv->id_table;
> +
> struct hid_dynid *dynid;
> __u32 bus, vendor, product;
> unsigned long driver_data = 0;
> @@ -2657,6 +2659,22 @@ static ssize_t new_id_store(struct device_driver *drv, const char *buf,
> if (ret < 3)
> return -EINVAL;
>
> + /* Only accept driver_data values that match an
> + * existing id_table entry
> + */
> + if (ids) {
> + ret = -EINVAL;
> + while (ids->bus) {
> + if (driver_data == ids->driver_data) {
> + ret = 0;
> + break;
> + }
> + ids++;
> + }
> + if (ret) /* No match */
> + return ret;
> + }
> +
[Severity: High]
Does this change break backward compatibility and the intended purpose of the
new_id interface?
Previously, users could write just the bus, vendor, and product to new_id,
leaving driver_data to default to 0. With this patch, if a driver's id_table
only contains entries with non-zero driver_data (such as quirk bitmasks in
hid-apple), wouldn't the sysfs write now fail with -EINVAL?
Additionally, does this prevent developers from testing unsupported hardware
by passing custom quirk bitmasks (or passing 0 to test without quirks) via
the driver_data field?
> dynid = kzalloc_obj(*dynid);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-mod-devicetable-hid_device_id-v2-0-a1d7473ccd9c@thegoodpenguin.co.uk?part=11
^ permalink raw reply
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