Re: [PATCH] iio: accel: bmc150: clamp the device-reported FIFO frame count

[Bryam Vargas]

A couple of things that belong with the patch I just sent: the reproducer
I used, and a heads-up about an in-flight series on this file.

Reproducer
==========
I reproduced the out-of-bounds write with an in-kernel test that drives the
__bmc150_accel_fifo_flush() buffer geometry verbatim under KASAN
(CONFIG_KASAN_STACK=y), with the device-supplied frame count:

  count=127, samples=0 (flush-all), no clamp:
    BUG: KASAN: stack-out-of-bounds in ...fifo_flush
    Write of size 762 ... 'buffer'   (the 192-byte buffer)
  with the patch (clamp to BMC150_ACCEL_FIFO_LENGTH): the transfer is
    bounded to 32 samples, no KASAN report.
  a well-formed (<= 32 sample) flush is unaffected, no KASAN report.

The full 762-byte write -- a 570-byte overflow past buffer[] that smashes the
stack canary and the return address -- reproduces the same way under userspace
AddressSanitizer on -m32 and -m64. The FIFO frame count is read over I2C/SPI
from the accelerometer, so triggering this requires a malicious or defective
device, or tampering on the bus. No CVE has been assigned.

In-flight series on this file
=============================
There is an in-flight cleanup from Gabriel Rondon converting this driver's
locking to guard(mutex):

  [PATCH v3] iio: accel: bmc150: use guard(mutex) for mutex handling
  https://lore.kernel.org/all/20260525110130.61284-1-grondon@xxxxxxxxx/

That series only rewrites the mutex_lock()/mutex_unlock() pairs -- including
the bmc150_accel_fifo_flush() wrapper -- and does not touch the count handling
in __bmc150_accel_fifo_flush(), so this fix is independent of it and the two
apply cleanly together. This patch is against mainline; if the guard(mutex)
series lands first it needs only a context-line refresh.

Thanks,
Bryam