drivers/iio/accel/adxl380.c | 1 + 1 file changed, 1 insertion(+)
The FIFO entry count is a 9-bit device-reported value and can therefore
be as large as 511. fifo_buf[], however, only has room for
ADXL380_FIFO_SAMPLES (315) entries.
After rounding the count down to a multiple of fifo_set_size,
adxl380_irq_handler() uses it directly as the length of a bulk FIFO
read. If the reported count exceeds ADXL380_FIFO_SAMPLES, this can
overflow fifo_buf.
Clamp the reported entry count to the size of fifo_buf before rounding
it down.
Fixes: df36de13677a ("iio: accel: add ADXL380 driver")
Cc: stable@vger.kernel.org
Assisted-by: GLM:5.2
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
---
drivers/iio/accel/adxl380.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
index 7dca5523091fc4c6a3c3bf7e388d5d0d507bee19..8a9d82e1d882aa45721013590ecbd86b083a15a6 100644
--- a/drivers/iio/accel/adxl380.c
+++ b/drivers/iio/accel/adxl380.c
@@ -966,6 +966,7 @@ static irqreturn_t adxl380_irq_handler(int irq, void *p)
if (ret)
return IRQ_HANDLED;
+ fifo_entries = min(fifo_entries, ADXL380_FIFO_SAMPLES);
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);
---
base-commit: 848acc8ffe1b7cd5f1bf427b93069becfebc2c9d
change-id: 20260809-adxl380-fifo-clamp-f07a570d96b1
Best regards,
--
Shengzhuo Wei <me@cherr.cc>On Sun, 09 Aug 2026 06:18:51 +0800
"Shengzhuo Wei" <me@cherr.cc> wrote:
> The FIFO entry count is a 9-bit device-reported value and can therefore
> be as large as 511. fifo_buf[], however, only has room for
> ADXL380_FIFO_SAMPLES (315) entries.
>
> After rounding the count down to a multiple of fifo_set_size,
> adxl380_irq_handler() uses it directly as the length of a bulk FIFO
> read. If the reported count exceeds ADXL380_FIFO_SAMPLES, this can
> overflow fifo_buf.
>
> Clamp the reported entry count to the size of fifo_buf before rounding
> it down.
>
> Fixes: df36de13677a ("iio: accel: add ADXL380 driver")
In my opinion at least, these are not fixes. In general we don't expect
drivers to be hardened against broken hardware returning out of spec
values. I don't mind taking simple cases though that don't complicate
the code much and if anything make it a little easier to follow,
but I don't currently see any reason to mark them as a fix.
So drop that tag for v2.
> Cc: stable@vger.kernel.org
> Assisted-by: GLM:5.2
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
> ---
> drivers/iio/accel/adxl380.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
> index 7dca5523091fc4c6a3c3bf7e388d5d0d507bee19..8a9d82e1d882aa45721013590ecbd86b083a15a6 100644
> --- a/drivers/iio/accel/adxl380.c
> +++ b/drivers/iio/accel/adxl380.c
> @@ -966,6 +966,7 @@ static irqreturn_t adxl380_irq_handler(int irq, void *p)
> if (ret)
> return IRQ_HANDLED;
>
> + fifo_entries = min(fifo_entries, ADXL380_FIFO_SAMPLES);
This is papering over what we think is a hardware failure. Unless I am
missing something the device is returning garbage, otherwise we are in
range and this has no affect. We have no idea how much data there is
if we get a value outside the expected range.
As such I'd expect an error print and probably no attempt to carry
on reading as we have no idea what happened.
> 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);
>
> ---
> base-commit: 848acc8ffe1b7cd5f1bf427b93069becfebc2c9d
> change-id: 20260809-adxl380-fifo-clamp-f07a570d96b1
>
> Best regards,
在 2026-08-10 00:28，Jonathan Cameron 写道：
> > Fixes: df36de13677a ("iio: accel: add ADXL380 driver")
>
> In my opinion at least, these are not fixes. In general we don't expect
> drivers to be hardened against broken hardware returning out of spec
> values. I don't mind taking simple cases though that don't complicate
> the code much and if anything make it a little easier to follow,
> but I don't currently see any reason to mark them as a fix.
>
> So drop that tag for v2.
>
Hi Jonathan,
Thanks. Understood — I'll drop the Fixes tag and stop clamping.
> This is papering over what we think is a hardware failure. Unless I am
> missing something the device is returning garbage, otherwise we are in
> range and this has no affect. We have no idea how much data there is
> if we get a value outside the expected range.
>
> As such I'd expect an error print and probably no attempt to carry
> on reading as we have no idea what happened.
For v2 I'll treat an out-of-range count as a hardware error,
log it, and skip the read rather than carrying on:
ret = adxl380_get_fifo_entries(st, &fifo_entries);
if (ret)
return IRQ_HANDLED;
if (fifo_entries > ADXL380_FIFO_SAMPLES) {
dev_err_ratelimited(st->dev,
"invalid FIFO entry count %u (max %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);
Same for adxl367 (push_fifo_data: dev_err_ratelimited and return true
without reading the FIFO).
I'll send the two as a single series with a cover letter, no Fixes tags.
Let me know if this looks OK to you, or if you'd change anything, and
I'll send the v2 series.
Best regards,
Shengzhuo Wei
On Mon, 10 Aug 2026 13:06:01 +0800
"Shengzhuo Wei" <me@cherr.cc> wrote:
> 在 2026-08-10 00:28，Jonathan Cameron 写道：
> > > Fixes: df36de13677a ("iio: accel: add ADXL380 driver")
> >
> > In my opinion at least, these are not fixes. In general we don't expect
> > drivers to be hardened against broken hardware returning out of spec
> > values. I don't mind taking simple cases though that don't complicate
> > the code much and if anything make it a little easier to follow,
> > but I don't currently see any reason to mark them as a fix.
> >
> > So drop that tag for v2.
> >
>
> Hi Jonathan,
>
> Thanks. Understood — I'll drop the Fixes tag and stop clamping.
>
> > This is papering over what we think is a hardware failure. Unless I am
> > missing something the device is returning garbage, otherwise we are in
> > range and this has no affect. We have no idea how much data there is
> > if we get a value outside the expected range.
> >
> > As such I'd expect an error print and probably no attempt to carry
> > on reading as we have no idea what happened.
>
> For v2 I'll treat an out-of-range count as a hardware error,
> log it, and skip the read rather than carrying on:
>
> ret = adxl380_get_fifo_entries(st, &fifo_entries);
> if (ret)
> return IRQ_HANDLED;
>
> if (fifo_entries > ADXL380_FIFO_SAMPLES) {
> dev_err_ratelimited(st->dev,
> "invalid FIFO entry count %u (max %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);
>
> Same for adxl367 (push_fifo_data: dev_err_ratelimited and return true
> without reading the FIFO).
>
> I'll send the two as a single series with a cover letter, no Fixes tags.
>
> Let me know if this looks OK to you, or if you'd change anything, and
> I'll send the v2 series.
>
Looks good to me. The rate limit is interesting but perhaps does make
sense here given we are kind of assuming the hardware is stuck in
a bad condition. On the other hand, it's complexity for a path we
never expect to take in practice. Definitely make sure to add a
brief description of why that is used in the patch description.
Thanks
Jonathan
> Best regards,
> Shengzhuo Wei
>
© 2016 - 2026 Red Hat, Inc.