Re: [PATCH] iio: pressure: bmp280: zero-init bmp580 trigger handler buffer

[David CARLIER]

Hi Jonathan,

sorry those messages had been buried among others, I just missed them,
apologies for the slow reply.

On Sat, 16 May 2026 at 11:25, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
> On Wed, 6 May 2026 12:14:12 +0300
> Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:
>
> > On Tue, May 05, 2026 at 06:34:55PM +0100, David Carlier wrote:
> > > bmp580_trigger_handler() builds an on-stack scan buffer containing
> > > two __le32 fields and an aligned_s64 timestamp, and pushes it to
> > > userspace via iio_push_to_buffers_with_ts(). However, only the low
> > > 3 bytes of each __le32 field are populated by the device data:
> > >
> > >     memcpy(&buffer.comp_press, &data->buf[3], 3);
> > >     memcpy(&buffer.comp_temp,  &data->buf[0], 3);
> > >
> > > The high byte of each field is left uninitialised on the stack.
> > > The bmp580 channels declare storagebits = 32, so the IIO core
> > > transports all four bytes per sample to userspace as part of the
> > > scan element, leaking two bytes of kernel stack per scan.
> > >
> > > Zero-initialise the buffer before populating it, mirroring the fix
> > > applied to bme280_trigger_handler() in commit 018f50909e66 ("iio:
> > > bmp280: zero-init buffer").
> >
> > Same Q, is any part of the above, including the initial report/analysis
> > AI assisted? If so, you have to mentioned this in the respective
> > Reported-by:/Closes:/et cetera tags.
>
> David, these questions are outstanding if you have time to look at them.
> I might be ok adding tags.
>
> Rather than risk losing the fix I've applied it with the tweak
> as Andy suggests below.
>
> Thanks,
>
> Jonathan
>
> >
> > ...
> >
> > >     } buffer;
> >
> >       } buffer = { };
> >
> > will suffice.
> >
> > >     int ret;
> > >
> > > +   memset(&buffer, 0, sizeof(buffer));
> >
>


To answer Andy's question: yes, the bug was found during an
  AI-assisted audit of IIO trigger-handler scan buffers (Claude,
  Anthropic). The tool flagged the partial 3-byte memcpy into a
  32-bit storagebits scan element; I confirmed the leak by reading
  the surrounding code (storagebits/realbits in the channel spec
  and the iio_push_to_buffers_with_ts() path) and by checking the
  prior fix 018f50909e66 ("iio: bmp280: zero-init buffer") that
  addresses the analogous bme280 case. I have not exercised the
  bmp580 path on hardware.

  I'm happy with whatever tag form you prefer. A note in the
  changelog along the lines of:

    Reported-by: Claude 4.6 at the time I believe

  or simply a sentence in the commit body stating the analysis was
  AI-assisted, would both be fine by me.

  Thanks,
  David