Re: [PATCH v2 5/7] iio: orientation: hid-sensor-incl-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] 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