Re: [PATCH 1/7] iio: gyro: hid-sensor-gyro-3d: use u32 instead of unsigned

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The capture_sample callback casts the `raw_data` pointer to `u32*` and `s64*` without validating `raw_len` or pointer alignment, potentially causing out-of-bounds reads, kernel memory leaks, and unaligned access faults.
--

commit e250748ae8811d708c463dcef4e525db238816e3
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>

iio: gyro: hid-sensor-gyro-3d: use u32 instead of unsigned

This commit replaces bare unsigned variables with the u32 type in the HID
sensor 3D gyro driver to improve code clarity and adhere to kernel style
guidelines.

> diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> index e48c25c87b6d6..bbca2111e79bb 100644
> --- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> +++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
[ ... ]
> @@ -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)
>  {

[Severity: High]
This is a pre-existing issue, but looking at the rest of this function, it
appears we cast the raw_data pointer directly to u32* and s64* without checking
raw_len or alignment:

gyro_3d_capture_sample() {
	...
	gyro_state->scan.gyro_val[CHANNEL_SCAN_INDEX_X + offset] =
			*(u32 *)raw_data;
	...
	gyro_state->timestamp =
		hid_sensor_convert_timestamp(&gyro_state->common_attributes,
					     *(s64 *)raw_data);
	...
}

Could a buggy or malicious HID device supply a field size smaller than 4 or 8
bytes, leading to an out-of-bounds read that leaks kernel heap data into the
IIO buffer?

Also, since raw_data is only guaranteed to be byte-aligned, could these native
casts trigger unaligned access exceptions on architectures that do not support
unaligned loads? Would it be safer to validate raw_len and use get_unaligned()
or memcpy() here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260606-6-june-hid-iio-correct-usage-id-v1-0-dd4a6820b674@gmail.com?part=1