This issue was found after attempting to make the same mistake for a driver I maintain, which was fortunately spotted by Jonathan [1].
Keeping old sensor values if the channel configuration changes is known and not considered an issue, which is also mentioned in [1], so it has not been addressed by this series. That keeps most of the drivers out of the way because they store the scan element in iio private data, which is kzalloc() allocated.
This series only addresses cases where uninitialized i.e. unknown data is pushed to the userspace, either due to holes in structs or uninitialized struct members/array elements.
While analyzing involved functions, I found and fixed some triviality (wrong function name) in the documentation of iio_dev_opaque.
Link: https://lore.kernel.org/linux-iio/20241123151634.303aa860@jic23-huawei/ [1]
Signed-off-by: Javier Carrasco javier.carrasco.cruz@gmail.com --- Changes in v2: - as73211.c: shift channels if no temperature is available and initialize chan[3] to zero. - Link to v1: https://lore.kernel.org/r/20241125-iio_memset_scan_holes-v1-0-0cb6e98d895c@g...
--- Javier Carrasco (2): iio: temperature: tmp006: fix information leak in triggered buffer iio: light: as73211: fix channel handling in only-color triggered buffer
drivers/iio/light/as73211.c | 17 +++++++++++++---- drivers/iio/temperature/tmp006.c | 2 ++ 2 files changed, 15 insertions(+), 4 deletions(-) --- base-commit: 1694dea95b02eff1a64c893ffee4626df533b2ab change-id: 20241123-iio_memset_scan_holes-a673833ef932
Best regards,