Re: [PATCH] iio: pressure: bmp280: fix out-of-bounds access in sampling frequency lookup
Andy Shevchenko <[email protected]>
| Newsgroups | org.kernel.vger.linux-kernel,org.kernel.vger.linux-iio,org.kernel.vger.stable |
|---|---|
| Organization | Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo |
| Message-ID | <[email protected]> |
On Wed, Aug 05, 2026 at 03:41:27PM +0800, Hui Su wrote:
> The sampling frequency tables store each frequency as an integer part
> and a fractional part in micro units. num_sampling_freq_avail is
> initialized to the number of flattened integer elements because
> read_avail() returns the table as a flat array.
>
> bmp280_write_sampling_frequency(), however, indexes the same table as a
> two-dimensional array and uses num_sampling_freq_avail as the number of
> rows. This makes the lookup walk past the end of the table when an
> unsupported sampling frequency is written.
>
> Convert the flattened element count back to the number of rows before
> iterating over the table.
...
> static int bmp280_write_sampling_frequency(struct bmp280_data *data,
> int val, int val2)
> {
> const int (*avail)[2] = data->chip_info->sampling_freq_avail;
> - const int n = data->chip_info->num_sampling_freq_avail;
> + const int n = data->chip_info->num_sampling_freq_avail /
> + ARRAY_SIZE(*avail);
For the consistency's sake use just plain 2 as initialisators do.
...
Nice catch! This seems to work because the page is present, but after this
array it contains some garbage that doesn't induce page fault, otherwise this
must have led to oops very easily (and no one reported it before).
--
With Best Regards,
Andy Shevchenko