Skip to contentSkip to conversation

iio: pressure: bmp280: zero-init bmp580 trigger handler buffer

PATCH In review David Carlier 3 participants 4 messages May 5 – May 16

Subsystems (2)
Stable branch IIO
lore
Share & tools
lore

David Carlier

author
#0 lore raw

PATCH 1/1 iio: pressure: bmp280: zero-init bmp580 trigger handler buffer

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 [email protected]
Signed-off-by David Carlier <[email protected]>
---
 drivers/iio/pressure/bmp280-core.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/iio/pressure/bmp280-core.c +2 -0
index f37f20776c89..431476cff883 100644
@@ -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 */
Signature · 1 line
2.53.0
#1 lore raw
Quoted 8 lines · 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);
Quoted 8 lines

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.

...

Quoted 1 line

} buffer;

} buffer = { };

will suffice.

Quoted 3 lines
drivers/iio/pressure/bmp280-core.c +1 -0
 	int ret;
 
+	memset(&buffer, 0, sizeof(buffer));
Signature · 2 lines
With Best Regards,
Andy Shevchenko
maintainer
#2 lore raw
Quoted 14 lines · On Wed, 6 May 2026 12:14:12 +0300 Andy Shevchenko…
Quoted 13 lines · 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.

Quoted 7 lines
Quoted 3 lines

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

Quoted 13 lines

...

Quoted 1 line

} buffer;

} buffer = { };

will suffice.

Quoted 3 lines
drivers/iio/pressure/bmp280-core.c +1 -0
 	int ret;
 
+	memset(&buffer, 0, sizeof(buffer));
author
#3 lore raw

Hi Jonathan,

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

Quoted 29 lines · Jonathan Cameron
Quoted 14 lines · On Wed, 6 May 2026 12:14:12 +0300 Andy Shevchenko…
Quoted 13 lines · 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.

Quoted 7 lines
Quoted 3 lines

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.

Quoted 21 lines

Rather than risk losing the fix I've applied it with the tweak as Andy suggests below.

Thanks,

Jonathan

Quoted 13 lines

...

Quoted 1 line
    } buffer;
      } buffer = { };

will suffice.

Quoted 3 lines
    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