Re: [PATCH V7 10/11] iio: imu: inv_icm42607: Add Gyroscope to icm42607

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Critical] The bounds check in `inv_icm42607_gyro_parse_fifo()` is inverted, dropping valid packets and causing out-of-bounds memory reads.
- [High] The local variable `gyro_ts` is passed uninitialized to `inv_sensors_timestamp_interrupt()` in `inv_icm42607_buffer_hwfifo_flush()`.
- [High] Missing lock acquisition in `inv_icm42607_gyro_hwfifo_flush()` allows concurrent data races over shared FIFO state.
- [High] Missing PM runtime acquisition in `inv_icm42607_gyro_hwfifo_set_watermark()`.
- [Medium] `inv_icm42607_gyro_read_avail()` exposes uninitialized padding as valid sampling frequencies to user-space.
--

commit 207799d1c88894b8f276d2717bc0960a73f7d744
Author: Chris Morgan <macromorgan@hotmail.com>

    iio: imu: inv_icm42607: Add Gyroscope to icm42607

This commit adds gyroscope functions to the inv_icm42607 driver.

> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> index 4371f428cc3f8..771120fa8ebf8 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
[ ... ]
> @@ -499,9 +512,10 @@ int inv_icm42607_buffer_fifo_parse(struct inv_icm42607_state *st)
>  int inv_icm42607_buffer_hwfifo_flush(struct inv_icm42607_state *st,
>  				     unsigned int count)
>  {
> +	struct inv_icm42607_sensor_state *gyro_st = iio_priv(st->indio_gyro);
>  	struct inv_icm42607_sensor_state *accel_st = iio_priv(st->indio_accel);
>  	struct inv_sensors_timestamp *ts;
> -	s64 accel_ts;
> +	s64 gyro_ts, accel_ts;
>  	int ret;
>  
>  	accel_ts = iio_get_time_ns(st->indio_accel);
[ ... ]
> @@ -513,6 +527,14 @@ int inv_icm42607_buffer_hwfifo_flush(struct inv_icm42607_state *st,
>  	if (st->fifo.nb.total == 0)
>  		return 0;
>  
> +	if (st->fifo.nb.gyro > 0) {
> +		ts = &gyro_st->ts;
> +		inv_sensors_timestamp_interrupt(ts, st->fifo.nb.gyro, gyro_ts);

Is it possible that gyro_ts is used uninitialized here? It appears to be
declared on the stack but never assigned a value, which would feed kernel
stack memory into the timestamp state machine.

> +		ret = inv_icm42607_gyro_parse_fifo(st->indio_gyro);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	if (st->fifo.nb.accel > 0) {
>  		ts = &accel_st->ts;
>  		inv_sensors_timestamp_interrupt(ts, st->fifo.nb.accel, accel_ts);
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> new file mode 100644
> index 0000000000000..5a5fd13ba64ec
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
[ ... ]
> +static int inv_icm42607_gyro_read_avail(struct iio_dev *indio_dev,
> +					struct iio_chan_spec const *chan,
> +					const int **vals,
> +					int *type, int *length, long mask)
> +{
> +	if (chan->type != IIO_ANGL_VEL)
> +		return -EINVAL;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_SCALE:
> +		*vals = (const int *)inv_icm42607_gyro_scale_nano;
> +		*type = IIO_VAL_INT_PLUS_NANO;
> +		*length = ARRAY_SIZE(inv_icm42607_gyro_scale_nano) * 2;
> +		return IIO_AVAIL_LIST;
> +	case IIO_CHAN_INFO_SAMP_FREQ:
> +		*vals = (const int *)inv_icm42607_gyro_odr;
> +		*type = IIO_VAL_INT_PLUS_MICRO;
> +		*length = ARRAY_SIZE(inv_icm42607_gyro_odr) * 2;

Could this expose uninitialized padding to user-space?

Because inv_icm42607_gyro_odr is initialized with designated initializers
starting at index 5, the first 5 entries are implicitly zero-initialized.
Returning the entire array length might expose these 0.000000 values as valid
sampling frequencies in the sampling_frequency_available sysfs attribute.

> +		return IIO_AVAIL_LIST;
> +	default:
> +		return -EINVAL;
> +	}
> +}
[ ... ]
> +static int inv_icm42607_gyro_hwfifo_set_watermark(struct iio_dev *indio_dev,
> +						  unsigned int val)
> +{
> +	struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> +
> +	guard(mutex)(&st->lock);
> +
> +	st->fifo.watermark.gyro = val;
> +	return inv_icm42607_buffer_update_watermark(st);

Is a PM runtime reference required here before updating the watermark?

inv_icm42607_buffer_update_watermark() modifies hardware registers, but this
function doesn't acquire a PM runtime reference. This might result in writing
to the device while it is suspended.

> +}
> +
> +static int inv_icm42607_gyro_hwfifo_flush(struct iio_dev *indio_dev,
> +					  unsigned int count)
> +{
> +	struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> +	struct device *dev = regmap_get_device(st->map);
> +	int ret;
> +
> +	if (count == 0)
> +		return 0;
> +
> +	/* Make sure we don't try to count more than the buffer can hold. */
> +	count = min(count, sizeof(st->fifo.data));
> +
> +	PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> +	if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> +		return -ENXIO;
> +
> +	ret = inv_icm42607_buffer_hwfifo_flush(st, count);

Does this need to acquire st->lock before calling
inv_icm42607_buffer_hwfifo_flush()?

Because inv_icm42607_buffer_hwfifo_flush() calls inv_icm42607_gyro_parse_fifo()
without holding the lock, an interrupt could fire concurrently and overwrite
st->fifo.data and st->fifo.count while they are being parsed locklessly.

> +	if (ret)
> +		return ret;
> +
> +	return st->fifo.nb.gyro;
> +}
[ ... ]
> +int inv_icm42607_gyro_parse_fifo(struct iio_dev *indio_dev)
> +{
> +	struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> +	struct inv_icm42607_sensor_state *gyro_st = iio_priv(indio_dev);
> +	struct inv_sensors_timestamp *ts = &gyro_st->ts;
> +	ssize_t i, size;
> +	unsigned int no;
> +	const void *accel, *gyro, *timestamp;
> +	const s8 *temp;
> +	unsigned int odr;
> +	s64 ts_val;
> +	struct inv_icm42607_gyro_buffer buffer = { };
> +
> +	/* parse all fifo packets */
> +	for (i = 0, no = 0; i < st->fifo.count; i += size, ++no) {
> +		size = inv_icm42607_fifo_decode_packet(&st->fifo.data[i],
> +				&accel, &gyro, &temp, &timestamp, &odr);
> +		/* quit if error or FIFO is empty */
> +		if (size <= 0)
> +			return size;
> +
> +		/* If the packet size could cause us to overflow, return. */
> +		if (i + size <= st->fifo.count)

Is this bounds check inverted?

It appears this condition evaluates to true when the packet fits safely within
the buffer, causing it to abort on valid data. Conversely, if a packet size
exceeds the buffer, the condition evaluates to false and allows the subsequent
memcpy() to read out of bounds.

> +			return -EIO;
> +
> +		/* skip packet if no gyro data or data is invalid */
> +		if (gyro == NULL || !inv_icm42607_fifo_is_data_valid(gyro))
> +			continue;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515130018.237378-1-macroalpha82@gmail.com?part=10