Re: [PATCH v5 7/8] iio: light: ltr501: Fix sorting order of device arrays

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] regmap_bulk_read and regmap_bulk_write are called with pointers to 32-bit integers, causing uninitialized memory reads and broken writes on big-endian architectures.
--

--- Patch [7]: [PATCH v5 7/8] iio: light: ltr501: Fix sorting order of device arrays ---
commit f69f1a2e0acaf6c0331bd3c3b614102addd48332
Author: Esben Haabendal <esben@geanix.com>

iio: light: ltr501: Fix sorting order of device arrays

This commit reorders the device array initializations in the ltr501 driver
to use alphanumerical sort order. This helps keep the elements in sync
across different tables and reduces merge conflicts.

> diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
> index 51ab387f24a32..d9b68da2452ba 100644
> --- a/drivers/iio/light/ltr501.c
> +++ b/drivers/iio/light/ltr501.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but does ltr501_read_thresh() leak uninitialized
kernel stack memory to userspace on big-endian systems?

drivers/iio/light/ltr501.c:ltr501_read_thresh() {
	...
	int ret, thresh_data;

	switch (chan->type) {
	case IIO_INTENSITY:
		switch (dir) {
		case IIO_EV_DIR_RISING:
			ret = regmap_bulk_read(data->regmap,
					       LTR501_ALS_THRESH_UP,
					       &thresh_data, 2);
			if (ret < 0)
				return ret;
			*val = thresh_data & LTR501_ALS_THRESH_MASK;
	...
}

Because regmap_bulk_read() reads only 2 bytes into the 32-bit int thresh_data,
the lower 16 bits remain uninitialized stack garbage on big-endian systems.
Masking with LTR501_ALS_THRESH_MASK then discards the valid device data and
exposes the uninitialized memory to userspace via the IIO sysfs interface.

Similarly, could ltr501_write_thresh() also be writing 0 instead of the target
threshold on big-endian architectures?

drivers/iio/light/ltr501.c:ltr501_write_thresh() {
	...
		case IIO_EV_DIR_RISING:
			mutex_lock(&data->lock_als);
			ret = regmap_bulk_write(data->regmap,
						LTR501_ALS_THRESH_UP,
						&val, 2);
			mutex_unlock(&data->lock_als);
			return ret;
	...
}

Writing 2 bytes from a 32-bit int on big-endian systems writes the top
2 bytes, which are likely 0, rather than the actual threshold value.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817-liteon-ltr329-v5-0-6f71ab2b0588@geanix.com?part=7