Re: [PATCH RFC v2 6/7] iio: osf: register IIO devices from capabilities

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The OPEN_SENSOR_FUSION Kconfig entry selects IIO_KFIFO_BUF without satisfying its IIO_BUFFER dependency.
- [High] Uninitialized kernel heap memory is leaked to userspace via the IIO buffer due to an unvalidated channel count.
- [High] Concurrent access to the shared `latest_samples` array without locking or memory barriers.
--

commit 699c891149ed43c06353cf9d1622dbd226109bd7
Author: Jinseob Kim <kimjinseob88@gmail.com>

iio: osf: register IIO devices from capabilities

Register supported IIO devices from the first valid capability report.

> diff --git a/drivers/iio/opensensorfusion/Kconfig b/drivers/iio/opensensorfusion/Kconfig
> index 360f25b4fe60b..004d2aa8ae10b 100644
> --- a/drivers/iio/opensensorfusion/Kconfig
> +++ b/drivers/iio/opensensorfusion/Kconfig
> @@ -5,11 +5,11 @@ config OPEN_SENSOR_FUSION
>  	depends on IIO
>  	depends on SERIAL_DEV_BUS
>  	select CRC32
> +	select IIO_KFIFO_BUF

[Severity: High]
Does this config also need to select or depend on IIO_BUFFER?

Since IIO_KFIFO_BUF is defined within an 'if IIO_BUFFER' block in the Kconfig
hierarchy, selecting it without having IIO_BUFFER enabled can cause unmet
direct dependency warnings and build failures if core IIO buffer support is
disabled.

>  	help
> -	  Build the Open Sensor Fusion UART receive path.
[ ... ]
> diff --git a/drivers/iio/opensensorfusion/osf_core.c b/drivers/iio/opensensorfusion/osf_core.c
> index c867b315865d2..a1e20ede9b149 100644
> --- a/drivers/iio/opensensorfusion/osf_core.c
> +++ b/drivers/iio/opensensorfusion/osf_core.c
[ ... ]
> +static int osf_core_handle_sensor_sample(struct osf_device *osf,
> +					 const struct osf_frame *frame)
>  {
> +	struct osf_latest_sample *latest;
[ ... ]
> +	latest->sensor_type = sample.sensor_type;
> +	latest->sensor_index = sample.sensor_index;
> +	latest->channel_count = sample.channel_count;
> +	latest->sample_format = sample.sample_format;
> +	latest->scale_nano = sample.scale_nano;
> +	latest->sequence = frame->sequence;
> +	latest->timestamp_us = frame->timestamp_us;
> +	latest->valid = true;

[Severity: High]
Can this array update cause data corruption for concurrent readers?

osf_core_handle_sensor_sample() updates the latest_samples array from the
serdev receive context, while osf_core_read_latest_sample() reads these
values from process context when userspace accesses sysfs attributes.

Since there is no synchronization like a mutex or seqlock protecting the
array, is it possible for readers to experience torn reads, partially
updated states, or see valid == true before the payload data is fully
committed?

> +	osf->last_sequence = frame->sequence;
> +
> +	indio_dev = osf_core_find_iio_dev(osf, sample.sensor_type,
> +					  sample.sensor_index);
> +	if (indio_dev) {
> +		ret = osf_iio_push_sample(indio_dev, latest->values,
> +					  latest->channel_count);

[Severity: High]
Could this leak uninitialized kernel heap memory to userspace?

The channel_count is assigned directly from the incoming network frame. If a
frame arrives with a smaller channel_count than the sensor's expected
num_channels, calling osf_iio_push_sample() ->
iio_push_to_buffers_with_ts_unaligned() allocates a bounce buffer using
devm_krealloc(..., GFP_KERNEL) which does not zero memory.

It then copies only channel_count * sizeof(s32) bytes into it. The remaining
space in the bounce buffer would be left uninitialized before being pushed to
the kfifo, potentially exposing kernel heap memory to userspace readers.

> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260524085312.15369-1-kimjinseob88@gmail.com?part=6