Re: [PATCH v2 2/7] iio: accel: hid-sensor-accel-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] 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