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

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

[David Carlier]

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").

Fixes: 872c8014e05e ("iio: pressure: bmp280: drop sensor_data array")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
---
 drivers/iio/pressure/bmp280-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/pressure/bmp280-core.c b/drivers/iio/pressure/bmp280-core.c
index f37f20776c89..431476cff883 100644
--- a/drivers/iio/pressure/bmp280-core.c
+++ b/drivers/iio/pressure/bmp280-core.c
@@ -2623,6 +2623,8 @@ static irqreturn_t bmp580_trigger_handler(int irq, void *p)
 	} buffer;
 	int ret;
 
+	memset(&buffer, 0, sizeof(buffer));
+
 	guard(mutex)(&data->lock);
 
 	/* Burst read data registers */
-- 
2.53.0

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

[Andy Shevchenko]

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.

...

>  	} buffer;

 	} buffer = { };

will suffice.

>  	int ret;
>  
> +	memset(&buffer, 0, sizeof(buffer));

-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Cameron]

On Wed, 6 May 2026 12:14:12 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> 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));  
> 

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@kernel.org> wrote:
>
> On Wed, 6 May 2026 12:14:12 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> 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