[PATCH v2 0/2] iio: accel: reject out-of-range FIFO entry counts

Both adxl380 and adxl367 use a device-reported FIFO entry count directly
as the length of a burst read into a fixed-size fifo_buf[], without
checking it against the buffer capacity. A malfunctioning or malicious
device reporting more entries than the FIFO can hold causes a heap
out-of-bounds write past fifo_buf[].

Neither driver is reachable from untrusted userspace -- both sit behind
SPI/I2C -- so this is hardening against buggy hardware rather than a fix
for an exploitable bug. Following review feedback [1], the out-of-range
count is rejected with an error and the read is aborted rather than
clamped, and the message is ratelimited because the check runs from the
IRQ handler and a stuck device can trigger it repeatedly.

The overflow was confirmed for both drivers using KASAN repro modules:
  adxl380: slab-out-of-bounds Write of size 1022 (fifo_entries=511)
  adxl367: slab-out-of-bounds Write of size 2046 (fifo_entries=1023)

Changes since v1 [2][3]:
  - Drop Fixes:/Cc:stable -- this is hardening, not a fix.
  - Reject the count with dev_err_ratelimited + abort instead of
    clamping, per review.
  - Combine the adxl380 and adxl367 patches into a single series.

[1] https://lore.kernel.org/all/20260812060029.7dc3d25b@jic23-huawei/
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/

Signed-off-by: Shengzhuo Wei <[email protected]>
---
Shengzhuo Wei (2):
      iio: accel: adxl380: reject out-of-range FIFO entry count
      iio: accel: adxl367: reject out-of-range FIFO entry count

 drivers/iio/accel/adxl367.c | 8 ++++++++
 drivers/iio/accel/adxl380.c | 7 +++++++
 2 files changed, 15 insertions(+)
---
base-commit: 848acc8ffe1b7cd5f1bf427b93069becfebc2c9d
change-id: 20260812-adxl-fifo-4e46a0776798

Best regards,
-- 
Shengzhuo Wei <[email protected]>