[PATCH v3] iio: imu: inv_icm45600: clamp the device-reported FIFO sample count

[PATCH v3] iio: imu: inv_icm45600: clamp the device-reported FIFO sample count

[Bryam Vargas via B4 Relay]

From: Bryam Vargas <hexlabsecurity@proton.me>

inv_icm45600_buffer_fifo_read() uses the FIFO_COUNT the device reports,
unclamped, as the length of a regmap_noinc_read() into the fixed 8 KiB
st->fifo.data buffer. The only bound is the caller's "max", which the
interrupt path skips (it passes 0). A device, or an attacker on the bus,
reporting up to 65535 makes the read as large as ~1 MiB: a heap
out-of-bounds write of device-controlled data.

Clamp fifo_nb to the buffer capacity (INV_ICM45600_FIFO_SIZE_MAX /
packet_size) before the read, mirroring the watermark cap in
inv_icm45600_wm_truncate() and the sibling inv_icm42600 driver. The clamp
is a no-op for conforming hardware.

Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
v3 (Andy [2]): shrink the commit message; the register/byte detail, the
not-for-stable rationale and the introducing commit moved below the cut.
v2 (Jonathan [1]): use min() instead of min_t(size_t, ...), and drop the
backport tags -- this is hardening against a malformed device-reported
count, not reachable with conforming hardware ("nice to have hardening",
Jonathan).

[1] https://lore.kernel.org/all/20260614144557.196a5c4c@jic23-huawei/
[2] https://lore.kernel.org/all/ajEMfH-_76M1OBqE@ashevche-desk.local/
v1: https://lore.kernel.org/all/20260613-b4-disp-58b984f3-v1-1-352b2f925f58@proton.me/
v2: https://lore.kernel.org/all/20260615-b4-disp-feb19207-v2-1-2d36f1e5fc54@proton.me/

fifo_nb = le16_to_cpup(raw_fifo_count) is 0..65535; the interrupt handler
calls inv_icm45600_buffer_fifo_read(st, 0), so the "max" clamp is skipped,
and fifo_nb * packet_size (16 bytes per packet) reaches ~1 MiB into the
8 KiB st->fifo.data buffer. Present since 06674a72cf7a ("iio: imu:
inv_icm45600: add buffer support in iio devices"); not marked for stable as
it needs a malicious or defective device, or bus tampering.

Reproduced with an in-kernel KASAN litmus and a userspace ASan model:
without the clamp a FIFO_COUNT of 0x208 (520 packets -> 8320 bytes) gives a
slab-out-of-bounds write past the 8192-byte region, and the full magnitude
(0xFFFF -> 1048560 bytes) reproduces under ASan on x86_64 and i386; with the
clamp the read is bounded to the buffer. Reproducer and full logs available
on request.
---
 drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
index 2b9ea317385c..5cde42f70c2e 100644
--- a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
+++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
@@ -422,6 +422,9 @@ int inv_icm45600_buffer_fifo_read(struct inv_icm45600_state *st,
 	if (max > 0 && fifo_nb > max)
 		fifo_nb = max;
 
+	/* Limit to the internal buffer capacity; the count is device-provided. */
+	fifo_nb = min(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;
 	ret = regmap_noinc_read(st->map, INV_ICM45600_REG_FIFO_DATA,

---
base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
change-id: 20260616-b4-disp-76e3f743-98d24c7e6ae4

Best regards,
-- 
Bryam Vargas <hexlabsecurity@proton.me>

Re: [PATCH v3] iio: imu: inv_icm45600: clamp the device-reported FIFO sample count

[Andy Shevchenko]

On Tue, Jun 16, 2026 at 08:57:28PM -0500, Bryam Vargas via B4 Relay wrote:

> inv_icm45600_buffer_fifo_read() uses the FIFO_COUNT the device reports,
> unclamped, as the length of a regmap_noinc_read() into the fixed 8 KiB
> st->fifo.data buffer. The only bound is the caller's "max", which the
> interrupt path skips (it passes 0). A device, or an attacker on the bus,
> reporting up to 65535 makes the read as large as ~1 MiB: a heap
> out-of-bounds write of device-controlled data.
> 
> Clamp fifo_nb to the buffer capacity (INV_ICM45600_FIFO_SIZE_MAX /
> packet_size) before the read, mirroring the watermark cap in
> inv_icm45600_wm_truncate() and the sibling inv_icm42600 driver. The clamp
> is a no-op for conforming hardware.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3] iio: imu: inv_icm45600: clamp the device-reported FIFO sample count

[Jonathan Cameron]

On Tue, 16 Jun 2026 20:57:28 -0500
Bryam Vargas via B4 Relay <devnull+hexlabsecurity.proton.me@kernel.org> wrote:

> From: Bryam Vargas <hexlabsecurity@proton.me>
> 
> inv_icm45600_buffer_fifo_read() uses the FIFO_COUNT the device reports,
> unclamped, as the length of a regmap_noinc_read() into the fixed 8 KiB
> st->fifo.data buffer. The only bound is the caller's "max", which the
> interrupt path skips (it passes 0). A device, or an attacker on the bus,
> reporting up to 65535 makes the read as large as ~1 MiB: a heap
> out-of-bounds write of device-controlled data.
> 
> Clamp fifo_nb to the buffer capacity (INV_ICM45600_FIFO_SIZE_MAX /
> packet_size) before the read, mirroring the watermark cap in
> inv_icm45600_wm_truncate() and the sibling inv_icm42600 driver. The clamp
> is a no-op for conforming hardware.
> 
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
> ---
> v3 (Andy [2]): shrink the commit message; the register/byte detail, the
> not-for-stable rationale and the introducing commit moved below the cut.
> v2 (Jonathan [1]): use min() instead of min_t(size_t, ...), and drop the
> backport tags -- this is hardening against a malformed device-reported
> count, not reachable with conforming hardware ("nice to have hardening",
> Jonathan).
> 
> [1] https://lore.kernel.org/all/20260614144557.196a5c4c@jic23-huawei/
> [2] https://lore.kernel.org/all/ajEMfH-_76M1OBqE@ashevche-desk.local/
> v1: https://lore.kernel.org/all/20260613-b4-disp-58b984f3-v1-1-352b2f925f58@proton.me/
> v2: https://lore.kernel.org/all/20260615-b4-disp-feb19207-v2-1-2d36f1e5fc54@proton.me/
> 
> fifo_nb = le16_to_cpup(raw_fifo_count) is 0..65535; the interrupt handler
> calls inv_icm45600_buffer_fifo_read(st, 0), so the "max" clamp is skipped,
> and fifo_nb * packet_size (16 bytes per packet) reaches ~1 MiB into the
> 8 KiB st->fifo.data buffer. Present since 06674a72cf7a ("iio: imu:
> inv_icm45600: add buffer support in iio devices"); not marked for stable as
> it needs a malicious or defective device, or bus tampering.
> 
> Reproduced with an in-kernel KASAN litmus and a userspace ASan model:
> without the clamp a FIFO_COUNT of 0x208 (520 packets -> 8320 bytes) gives a
> slab-out-of-bounds write past the 8192-byte region, and the full magnitude
> (0xFFFF -> 1048560 bytes) reproduces under ASan on x86_64 and i386; with the
> clamp the read is bounded to the buffer. Reproducer and full logs available
> on request.
> ---
>  drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
> index 2b9ea317385c..5cde42f70c2e 100644
> --- a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
> +++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
> @@ -422,6 +422,9 @@ int inv_icm45600_buffer_fifo_read(struct inv_icm45600_state *st,
>  	if (max > 0 && fifo_nb > max)
>  		fifo_nb = max;
>  
> +	/* Limit to the internal buffer capacity; the count is device-provided. */
> +	fifo_nb = min(fifo_nb, INV_ICM45600_FIFO_SIZE_MAX / packet_size);
> +
It is a little odd to clamp against a value / packet size just to multiply it
by packet size.  However there is an oddity here in that we might not have
a fully number of packets in the 8KiB buffer.

Hmm. It actually is a though as the packets are either 8 or 16 bytes
(only the bigger one relevant here).

So could we just do this instead?
	st->fifo.count = min(fifo_nb * packet_size, INV_ICM45600_FIFO_SIZE_MAX);

Also to make this much easier to spot, can we actually use the define in
the allocation in _core.c to allocate the buffer?  That can be in the same
patch as it's all related, but needs a tiny comment in the patch description.

st->fifo.data = devm_kzalloc(dev, INV_ICM45600_FIFO_SIZE_MAX, GFP_KERNEL);


>  	/* Try to read all FIFO data in internal buffer. */
>  	st->fifo.count = fifo_nb * packet_size;
>  	ret = regmap_noinc_read(st->map, INV_ICM45600_REG_FIFO_DATA,
> 
> ---
> base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
> change-id: 20260616-b4-disp-76e3f743-98d24c7e6ae4
> 
> Best regards,

Re: [PATCH v3] iio: imu: inv_icm45600: clamp the device-reported FIFO sample count

[Bryam Vargas]

On 2026-06-21, Jonathan Cameron wrote:
> So could we just do this instead?
>     st->fifo.count = min(fifo_nb * packet_size, INV_ICM45600_FIFO_SIZE_MAX);

Yes, cleaner -- and safe here: fifo_nb isn't used past that line (the read, the
one-by-one fallback and the decode loop all bound on st->fifo.count), so
clamping the byte count is enough. fifo_nb is size_t and packet_size ssize_t, so
the multiply is 64-bit with no narrowing before the min. v4 will use it.

> can we actually use the define in the allocation in _core.c

Will do. It's devm_kzalloc(dev, 8192, ...) today and INV_ICM45600_FIFO_SIZE_MAX
is SZ_8K, so it's a no-op rename that ties the allocation to the clamp; folded
into the same patch with a changelog note.

v4 shortly.

Bryam