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

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

[Shengzhuo Wei]

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/20260809-adxl380-fifo-clamp-v1-1-780d86ef25eb@cherr.cc/
[3] https://lore.kernel.org/all/20260809-adxl367-fifo-clamp-v1-1-6eb35eaebcde@cherr.cc/

Signed-off-by: Shengzhuo Wei <me@cherr.cc>
---
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 <me@cherr.cc>

[PATCH v2 1/2] iio: accel: adxl380: reject out-of-range FIFO entry count

[Shengzhuo Wei]

The FIFO entry count is a 9-bit device-reported value, so it can be as
large as 511, but fifo_buf[] only has room for ADXL380_FIFO_SAMPLES
(315) entries. adxl380_irq_handler() uses the reported count directly as
the length of a bulk FIFO read, so a count above ADXL380_FIFO_SAMPLES
overflows fifo_buf, a heap out-of-bounds write of up to 392 bytes into
adjacent memory.

Rather than clamp the count and silently drop the excess, abort the
read: a count beyond the FIFO size means the device is returning
garbage, so the data cannot be trusted. The message is ratelimited
because a stuck device can raise the watermark IRQ repeatedly.

Assisted-by: GLM:5.2
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
---
 drivers/iio/accel/adxl380.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
index 7dca5523091fc4c6a3c3bf7e388d5d0d507bee19..8518ee23e114901ee02933e91b8bdf8d7c83008c 100644
--- a/drivers/iio/accel/adxl380.c
+++ b/drivers/iio/accel/adxl380.c
@@ -966,6 +966,13 @@ static irqreturn_t adxl380_irq_handler(int irq, void  *p)
 	if (ret)
 		return IRQ_HANDLED;
 
+	if (fifo_entries > ADXL380_FIFO_SAMPLES) {
+		dev_err_ratelimited(st->dev,
+				    "FIFO entry count %u exceeds FIFO size %lu\n",
+				    fifo_entries, ADXL380_FIFO_SAMPLES);
+		return IRQ_HANDLED;
+	}
+
 	fifo_entries = rounddown(fifo_entries, st->fifo_set_size);
 	ret = regmap_noinc_read(st->regmap, ADXL380_FIFO_DATA, &st->fifo_buf,
 				sizeof(*st->fifo_buf) * fifo_entries);

-- 
2.47.3

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

[Shengzhuo Wei]

The FIFO entry count reported by the device can be as large as 1023
(the low byte plus the low two bits of the high byte), but fifo_buf[]
only has room for ADXL367_FIFO_SIZE (512) entries.
adxl367_push_fifo_data() passes the reported count straight to the FIFO
read, so a count above ADXL367_FIFO_SIZE overflows fifo_buf, a heap
out-of-bounds write of up to 1022 bytes into adjacent memory.

Rather than clamp the count and silently drop the excess, abort the
read: a count beyond the FIFO size means the device is returning
garbage, so the data cannot be trusted. The message is ratelimited
because a stuck device can raise the IRQ repeatedly.

Assisted-by: GLM:5.2
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
---
 drivers/iio/accel/adxl367.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/iio/accel/adxl367.c b/drivers/iio/accel/adxl367.c
index 8c3de11a10a37d228f8758b688156e3ee958c4e9..270d6feede2f60f4274dead7b3974cd04abb14a6 100644
--- a/drivers/iio/accel/adxl367.c
+++ b/drivers/iio/accel/adxl367.c
@@ -787,6 +787,14 @@ static bool adxl367_push_fifo_data(struct iio_dev *indio_dev, u8 status,
 	if (!FIELD_GET(ADXL367_STATUS_FIFO_FULL_MASK, status))
 		return false;
 
+	if (fifo_entries > ADXL367_FIFO_SIZE) {
+		dev_err_ratelimited(st->dev,
+				    "FIFO entry count %u exceeds FIFO size %lu\n",
+				    fifo_entries,
+				    (unsigned long)ADXL367_FIFO_SIZE);
+		return true;
+	}
+
 	fifo_entries -= fifo_entries % st->fifo_set_size;
 
 	ret = st->ops->read_fifo(st->context, st->fifo_buf, fifo_entries);

-- 
2.47.3

Re: [PATCH v2 2/2] iio: accel: adxl367: reject out-of-range FIFO entry count

[Andy Shevchenko]

On Wed, Aug 12, 2026 at 03:58:50PM +0800, Shengzhuo Wei wrote:
> The FIFO entry count reported by the device can be as large as 1023
> (the low byte plus the low two bits of the high byte), but fifo_buf[]
> only has room for ADXL367_FIFO_SIZE (512) entries.
> adxl367_push_fifo_data() passes the reported count straight to the FIFO
> read, so a count above ADXL367_FIFO_SIZE overflows fifo_buf, a heap
> out-of-bounds write of up to 1022 bytes into adjacent memory.
> 
> Rather than clamp the count and silently drop the excess, abort the
> read: a count beyond the FIFO size means the device is returning
> garbage, so the data cannot be trusted. The message is ratelimited
> because a stuck device can raise the IRQ repeatedly.

Aren't they already were discussed in linux-iio@ mailing list earlier?

...

> +		dev_err_ratelimited(st->dev,
> +				    "FIFO entry count %u exceeds FIFO size %lu\n",
> +				    fifo_entries,
> +				    (unsigned long)ADXL367_FIFO_SIZE);

In majority of the explicit castings when printing a message they are wrong or
unneeded. Use correct format specifiers to begin with.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/2] iio: accel: adxl367: reject out-of-range FIFO entry count

[Jonathan Cameron]

On Wed, 12 Aug 2026 11:08:43 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Wed, Aug 12, 2026 at 03:58:50PM +0800, Shengzhuo Wei wrote:
> > The FIFO entry count reported by the device can be as large as 1023
> > (the low byte plus the low two bits of the high byte), but fifo_buf[]
> > only has room for ADXL367_FIFO_SIZE (512) entries.
> > adxl367_push_fifo_data() passes the reported count straight to the FIFO
> > read, so a count above ADXL367_FIFO_SIZE overflows fifo_buf, a heap
> > out-of-bounds write of up to 1022 bytes into adjacent memory.
> > 
> > Rather than clamp the count and silently drop the excess, abort the
> > read: a count beyond the FIFO size means the device is returning
> > garbage, so the data cannot be trusted. The message is ratelimited
> > because a stuck device can raise the IRQ repeatedly.  
> 
> Aren't they already were discussed in linux-iio@ mailing list earlier?

I'm lost.  Yes it was discussed a few times, one of them in the v1 thread
for this.  Andy, can you be a bit more specific on what you mean here.
I for one am half asleep today so could do with the pointer!

> 
> ...
> 
> > +		dev_err_ratelimited(st->dev,
> > +				    "FIFO entry count %u exceeds FIFO size %lu\n",
> > +				    fifo_entries,
> > +				    (unsigned long)ADXL367_FIFO_SIZE);  
> 
> In majority of the explicit castings when printing a message they are wrong or
> unneeded. Use correct format specifiers to begin with.
> 
This one I agree with - why would we print it as a long unsigned given it is the
constant 512?

Re: [PATCH v2 2/2] iio: accel: adxl367: reject out-of-range FIFO entry count

[Andy Shevchenko]

On Sun, Aug 16, 2026 at 01:53:58AM +0100, Jonathan Cameron wrote:
> On Wed, 12 Aug 2026 11:08:43 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Wed, Aug 12, 2026 at 03:58:50PM +0800, Shengzhuo Wei wrote:

...

> > Aren't they already were discussed in linux-iio@ mailing list earlier?
> 
> I'm lost.  Yes it was discussed a few times, one of them in the v1 thread
> for this.  Andy, can you be a bit more specific on what you mean here.
> I for one am half asleep today so could do with the pointer!

Sorry for the unclearness. I think I saw the similar discussion in the past
(but probably related to another driver in IIO with the similar symptoms).
I can't quickly find a pointer, I might have been hallucinating (luckily
it's not a property solely related to AI).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/2] iio: accel: adxl367: reject out-of-range FIFO entry count

[Jonathan Cameron]

On Wed, 12 Aug 2026 11:08:43 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Wed, Aug 12, 2026 at 03:58:50PM +0800, Shengzhuo Wei wrote:
> > The FIFO entry count reported by the device can be as large as 1023
> > (the low byte plus the low two bits of the high byte), but fifo_buf[]
> > only has room for ADXL367_FIFO_SIZE (512) entries.
> > adxl367_push_fifo_data() passes the reported count straight to the FIFO
> > read, so a count above ADXL367_FIFO_SIZE overflows fifo_buf, a heap
> > out-of-bounds write of up to 1022 bytes into adjacent memory.
> > 
> > Rather than clamp the count and silently drop the excess, abort the
> > read: a count beyond the FIFO size means the device is returning
> > garbage, so the data cannot be trusted. The message is ratelimited
> > because a stuck device can raise the IRQ repeatedly.  
> 
> Aren't they already were discussed in linux-iio@ mailing list earlier?
> 
> ...
> 
> > +		dev_err_ratelimited(st->dev,
> > +				    "FIFO entry count %u exceeds FIFO size %lu\n",
> > +				    fifo_entries,
> > +				    (unsigned long)ADXL367_FIFO_SIZE);  
> 
> In majority of the explicit castings when printing a message they are wrong or
> unneeded. Use correct format specifiers to begin with.
Even more odd when it's casting the number 512 to a long unsigned.

Applied both patches, this one with:

diff --git a/drivers/iio/accel/adxl367.c b/drivers/iio/accel/adxl367.c
index 67b317eec035..a597fee61105 100644
--- a/drivers/iio/accel/adxl367.c
+++ b/drivers/iio/accel/adxl367.c
@@ -789,9 +789,8 @@ static bool adxl367_push_fifo_data(struct iio_dev *indio_dev, u8 status,
 
        if (fifo_entries > ADXL367_FIFO_SIZE) {
                dev_err_ratelimited(st->dev,
-                                   "FIFO entry count %u exceeds FIFO size %lu\n",
-                                   fifo_entries,
-                                   (unsigned long)ADXL367_FIFO_SIZE);
+                                   "FIFO entry count %u exceeds FIFO size %u\n",
+                                   fifo_entries, ADXL367_FIFO_SIZE);
                return true;
        }
 

tweak

Jonathan

>