The IRQ path calls inv_icm45600_buffer_fifo_read(st, 0), so the raw
16-bit FIFO count sizes the read into st->fifo.data (8K). Cap the
packet count so the transfer cannot exceed that buffer.

Fixes: 06674a72cf7a ("iio: imu: inv_icm45600: add buffer support in iio devices")
Cc: stable@vger.kernel.org
Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
---
 drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
index 2b9ea317385c..62e9e138bc89 100644
--- a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
+++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
@@ -419,8 +419,10 @@ int inv_icm45600_buffer_fifo_read(struct inv_icm45600_state *st,
 	fifo_nb = le16_to_cpup(raw_fifo_count);
 	if (fifo_nb == 0)
 		return 0;
-	if (max > 0 && fifo_nb > max)
-		fifo_nb = max;
+	if (max > 0)
+		fifo_nb = min(fifo_nb, (size_t)max);
+	fifo_nb = min_t(size_t, fifo_nb,
+			INV_ICM45600_FIFO_SIZE_MAX / packet_size);
 
 	/* Try to read all FIFO data in internal buffer. */
 	st->fifo.count = fifo_nb * packet_size;
-- 
2.25.1

On Thu, 20 Aug 2026 15:02:08 +0800
Linkai Gong <gonglinkai@kylinos.cn> wrote:

> The IRQ path calls inv_icm45600_buffer_fifo_read(st, 0), so the raw
> 16-bit FIFO count sizes the read into st->fifo.data (8K). Cap the
> packet count so the transfer cannot exceed that buffer.
> 
> Fixes: 06674a72cf7a ("iio: imu: inv_icm45600: add buffer support in iio devices")
> Cc: stable@vger.kernel.org
> Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>

I believe this is fixed in the iio tree (and shortly upstream), though
in a slightly different way.

Fwiw I don't consider these fixes because the hardware doesn't return
out of range values - rather they are hardening against a potential problem.

A few other things inline.


> ---
>  drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
> index 2b9ea317385c..62e9e138bc89 100644
> --- a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
> +++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
> @@ -419,8 +419,10 @@ int inv_icm45600_buffer_fifo_read(struct inv_icm45600_state *st,
>  	fifo_nb = le16_to_cpup(raw_fifo_count);
>  	if (fifo_nb == 0)
>  		return 0;
> -	if (max > 0 && fifo_nb > max)
> -		fifo_nb = max;
> +	if (max > 0)
> +		fifo_nb = min(fifo_nb, (size_t)max);

This looks like an unrelated change. min is pretty flexible on inputs anyway
so perhaps this is fine without that cast.

> +	fifo_nb = min_t(size_t, fifo_nb,
> +			INV_ICM45600_FIFO_SIZE_MAX / packet_size);

Why is min_t needed?  It very rarely is given how min handles mixed types.

Maybe I'm missing something here but I'm not going to chase
it down given we already have a fix in place

Thanks,

Jonathan


>  
>  	/* Try to read all FIFO data in internal buffer. */
>  	st->fifo.count = fifo_nb * packet_size;

Hi Jonathan

On Fri, 21 Aug 2026 02:51:05 +0100, Jonathan Cameron wrote:
> I believe this is fixed in the iio tree (and shortly upstream), though
> in a slightly different way.

Sorry, I missed that. I'll drop this patch.

Thanks,
Linkai