drivers/iio/buffer/industrialio-hw-consumer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
was using list_for_each_entry() to iterate through buffers while calling
iio_buffer_put() which can free the current buffer if refcount drops to 0.
The list_for_each_entry() loop macro then evaluates buf->head.next to
continue iteration, accessing the freed buffer.
Fix this by using list_for_each_entry_safe().
Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
Reported-by: sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Changes in v2:
- Fix Andy's comment.
- Add Reported-by tag.
- Link to v1: https://lore.kernel.org/r/20260428-iio-buf-v1-1-dcc63ff7b800@gmail.com
---
drivers/iio/buffer/industrialio-hw-consumer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
index 24d7df603760..700528c9a0a4 100644
--- a/drivers/iio/buffer/industrialio-hw-consumer.c
+++ b/drivers/iio/buffer/industrialio-hw-consumer.c
@@ -85,7 +85,7 @@ static struct hw_consumer_buffer *iio_hw_consumer_get_buffer(
*/
struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev)
{
- struct hw_consumer_buffer *buf;
+ struct hw_consumer_buffer *buf, *tmp;
struct iio_hw_consumer *hwc;
struct iio_channel *chan;
int ret;
@@ -116,7 +116,7 @@ struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev)
return hwc;
err_put_buffers:
- list_for_each_entry(buf, &hwc->buffers, head)
+ list_for_each_entry_safe(buf, tmp, &hwc->buffers, head)
iio_buffer_put(&buf->buffer);
iio_channel_release_all(hwc->channels);
err_free_hwc:
---
base-commit: 7080e32d3f09d8688c4a87d81bdcc71f7f606b16
change-id: 20260428-iio-buf-4c8559020a54
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
On Thu, Apr 30, 2026 at 09:29:06PM +0800, Felix Gu wrote: > In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code > was using list_for_each_entry() to iterate through buffers while calling > iio_buffer_put() which can free the current buffer if refcount drops to 0. > The list_for_each_entry() loop macro then evaluates buf->head.next to > continue iteration, accessing the freed buffer. > > Fix this by using list_for_each_entry_safe(). Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> -- With Best Regards, Andy Shevchenko
On Thu, 30 Apr 2026 at 15:29, Felix Gu <ustc.gu@gmail.com> wrote:
>
> In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
> was using list_for_each_entry() to iterate through buffers while calling
> iio_buffer_put() which can free the current buffer if refcount drops to 0.
> The list_for_each_entry() loop macro then evaluates buf->head.next to
> continue iteration, accessing the freed buffer.
>
> Fix this by using list_for_each_entry_safe().
>
> Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
> Reported-by: sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com
FYI, Sashiko reported 2 additional regressions (neither introduced by
your patches), one of them critical. Maybe another patch would be good?
https://sashiko.dev/#/patchset/20260430-iio-buf-v2-1-84c2231dea5e%40gmail.com?part=1
--
Kind regards
CJD
On Fri May 1, 2026 at 9:19 AM CDT, Joshua Crofts wrote:
> On Thu, 30 Apr 2026 at 15:29, Felix Gu <ustc.gu@gmail.com> wrote:
>>
>> In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
>> was using list_for_each_entry() to iterate through buffers while calling
>> iio_buffer_put() which can free the current buffer if refcount drops to 0.
>> The list_for_each_entry() loop macro then evaluates buf->head.next to
>> continue iteration, accessing the freed buffer.
>>
>> Fix this by using list_for_each_entry_safe().
>>
>> Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
>> Reported-by: sashiko <sashiko-bot@kernel.org>
>> Closes: https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com
>
> FYI, Sashiko reported 2 additional regressions (neither introduced by
> your patches), one of them critical. Maybe another patch would be good?
>
> https://sashiko.dev/#/patchset/20260430-iio-buf-v2-1-84c2231dea5e%40gmail.com?part=1
>
I think one of the issues raised by sashiko has an active patch:
https://lore.kernel.org/linux-iio/20260427-iio_buf-v1-1-2bbdac844647@gmail.com/
and I think they were waiting for Nuno to review it, since they noted
they were on a "wild goose chase". Thus the only issue raised by sashiko
that would still need a patch would be the OOB issue, but I haven't
looked at its explaination thoroughly to see if it's hallucinating.
Anyways this one should still be good to merge.
best regards,
maxwell
> --
> Kind regards
>
> CJD
⁷ On Fri, 1 May 2026 at 17:47, Maxwell Doose <m32285159@gmail.com> wrote: > I think one of the issues raised by sashiko has an active patch: > > https://lore.kernel.org/linux-iio/20260427-iio_buf-v1-1-2bbdac844647@gmail.com/ > > and I think they were waiting for Nuno to review it, since they noted > they were on a "wild goose chase". Thus the only issue raised by sashiko > that would still need a patch would be the OOB issue, but I haven't > looked at its explaination thoroughly to see if it's hallucinating. > > Anyways this one should still be good to merge. > Yeah this is good to merge, I was only pointing out that Sashiko reported additional errors (unrelated to this patch, it seems to keep finding more issues with the driver). -- Kind regards CJD
On Fri May 1, 2026 at 2:40 PM CDT, Joshua Crofts wrote: > ⁷ > > On Fri, 1 May 2026 at 17:47, Maxwell Doose <m32285159@gmail.com> wrote: > >> I think one of the issues raised by sashiko has an active patch: >> >> https://lore.kernel.org/linux-iio/20260427-iio_buf-v1-1-2bbdac844647@gmail.com/ >> >> and I think they were waiting for Nuno to review it, since they noted >> they were on a "wild goose chase". Thus the only issue raised by sashiko >> that would still need a patch would be the OOB issue, but I haven't >> looked at its explaination thoroughly to see if it's hallucinating. >> >> Anyways this one should still be good to merge. >> > Yeah this is good to merge, I was only pointing out that > Sashiko reported additional errors (unrelated to this patch, > it seems to keep finding more issues with the driver). Also, if anybody feels strongly about the OOB issue that sashiko raised in iio_hw_consumer_alloc(), you can probably add something like: if (chan->channel->scan_index < 0) continue; but I feel at that point if that even happens there's something else seriously wrong. But it might be a good idea to add that check anyways, better safe than sorry. Not to mention, since this is a public function, we need to code far more defensively. best regards, maxwell
On Thu, 2026-04-30 at 21:29 +0800, Felix Gu wrote:
> In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
> was using list_for_each_entry() to iterate through buffers while calling
> iio_buffer_put() which can free the current buffer if refcount drops to 0.
> The list_for_each_entry() loop macro then evaluates buf->head.next to
> continue iteration, accessing the freed buffer.
>
> Fix this by using list_for_each_entry_safe().
>
> Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
> Reported-by: sashiko <sashiko-bot@kernel.org>
> Closes:
> https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> Changes in v2:
> - Fix Andy's comment.
> - Add Reported-by tag.
> - Link to v1:
> https://lore.kernel.org/r/20260428-iio-buf-v1-1-dcc63ff7b800@gmail.com
> ---
LGTM
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
> drivers/iio/buffer/industrialio-hw-consumer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c
> b/drivers/iio/buffer/industrialio-hw-consumer.c
> index 24d7df603760..700528c9a0a4 100644
> --- a/drivers/iio/buffer/industrialio-hw-consumer.c
> +++ b/drivers/iio/buffer/industrialio-hw-consumer.c
> @@ -85,7 +85,7 @@ static struct hw_consumer_buffer *iio_hw_consumer_get_buffer(
> */
> struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev)
> {
> - struct hw_consumer_buffer *buf;
> + struct hw_consumer_buffer *buf, *tmp;
> struct iio_hw_consumer *hwc;
> struct iio_channel *chan;
> int ret;
> @@ -116,7 +116,7 @@ struct iio_hw_consumer *iio_hw_consumer_alloc(struct device
> *dev)
> return hwc;
>
> err_put_buffers:
> - list_for_each_entry(buf, &hwc->buffers, head)
> + list_for_each_entry_safe(buf, tmp, &hwc->buffers, head)
> iio_buffer_put(&buf->buffer);
> iio_channel_release_all(hwc->channels);
> err_free_hwc:
>
> ---
> base-commit: 7080e32d3f09d8688c4a87d81bdcc71f7f606b16
> change-id: 20260428-iio-buf-4c8559020a54
>
> Best regards,
On Thu Apr 30, 2026 at 8:29 AM CDT, Felix Gu wrote:
> In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
> was using list_for_each_entry() to iterate through buffers while calling
> iio_buffer_put() which can free the current buffer if refcount drops to 0=
.
> The list_for_each_entry() loop macro then evaluates buf->head.next to
> continue iteration, accessing the freed buffer.
>
> Fix this by using list_for_each_entry_safe().
>
> Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
> Reported-by: sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647@gmail.com
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> Changes in v2:
> - Fix Andy's comment.
> - Add Reported-by tag.
> - Link to v1: https://lore.kernel.org/r/20260428-iio-buf-v1-1-dcc63ff7b80@gmail.com
> ---
> drivers/iio/buffer/industrialio-hw-consumer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Looks fine to me.
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
best regards,
maxwell
> Best regards,
> --=
> Felix Gu <ustc.gu@gmail.com>
On Thu, 30 Apr 2026 20:27:27 -0500
"Maxwell Doose" <m32285159@gmail.com> wrote:
> On Thu Apr 30, 2026 at 8:29 AM CDT, Felix Gu wrote:
> > In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
> > was using list_for_each_entry() to iterate through buffers while calling
> > iio_buffer_put() which can free the current buffer if refcount drops to 0=
> .
> > The list_for_each_entry() loop macro then evaluates buf->head.next to
> > continue iteration, accessing the freed buffer.
> >
> > Fix this by using list_for_each_entry_safe().
> >
> > Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
> > Reported-by: sashiko <sashiko-bot@kernel.org>
> > Closes: https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647@gmail.com
> > Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> > ---
> > Changes in v2:
> > - Fix Andy's comment.
> > - Add Reported-by tag.
> > - Link to v1: https://lore.kernel.org/r/20260428-iio-buf-v1-1-dcc63ff7b80@gmail.com
> > ---
> > drivers/iio/buffer/industrialio-hw-consumer.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Looks fine to me.
>
> Reviewed-by: Maxwell Doose <m32285159@gmail.com>
>
> best regards,
> maxwell
Applied to the fixes-togreg branch of iio.git and marked for stable.
Thanks
J
>
>
>
> > Best regards,
> > --=
> > Felix Gu <ustc.gu@gmail.com>
>
© 2016 - 2026 Red Hat, Inc.