[PATCH v2] iio: proximity: sx9324: fix out-of-bounds read of scan period table

[PATCH v2] iio: proximity: sx9324: fix out-of-bounds read of scan period table

[Arnav Kapoor]

The scan period of the SX9324 is selected by the 5 bit wide
SX9324_REG_GNRL_CTRL0_SCANPERIOD field, so it has 32 possible values.
sx9324_scan_period_table[] however only has 16 entries, it was copied
over from the SX9310 driver where the field is only 4 bits wide.

sx9324_wait_for_sample() indexes the table with the raw field value, so
all the codes from 16 to 31 read past the end of the array. The default
value of the register is SX9324_REG_GNRL_CTRL0_SCANPERIOD_100MS (0x16,
i.e. 22), so the out-of-bounds read happens with the default
configuration of the device. It is only avoided when the device has an
interrupt line, as the wait is only done in the polling case.

The value read is then used as the duration of an msleep() call, so the
sensor is polled with a completely random delay.

Fill the table with the scan periods of all 32 codes, which are the
periods documented for the corresponding sx9324_samp_freq_table[]
entries, and add a static assertion to keep both tables in sync.

Fixes: 4c18a890dff8 ("iio:proximity:sx9324: Add SX9324 support")
Cc: stable@vger.kernel.org
Signed-off-by: Arnav Kapoor <kapoorarnav43@gmail.com>
---
Changes in v2:
- Format sx9324_scan_period_table[] with a power-of-two number of entries
  (8) per line and the register value range as a comment at the end of
  each line, so the table is indexed and a typo is easy to find (Andy)
- Put the static_assert() on a single line (Andy)
- Add Fixes tag and Cc stable
- Rebase on fixes-togreg

v1: https://lore.kernel.org/all/20261021225417.626946-1-kapoorarnav43@gmail.com/

Compile-tested only (W=1); I don't have SX9324 hardware.

 drivers/iio/proximity/sx9324.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/proximity/sx9324.c b/drivers/iio/proximity/sx9324.c
index 255a36976ac4..43266a21bf2e 100644
--- a/drivers/iio/proximity/sx9324.c
+++ b/drivers/iio/proximity/sx9324.c
@@ -279,11 +279,20 @@ static const struct {
 	{ 0, 250000 },  /* 11111: 4 s */
 };
 
+/*
+ * The scan period of the SX9324 is selected by the 5 bit wide
+ * SX9324_REG_GNRL_CTRL0_SCANPERIOD field. The values below are the scan
+ * periods in ms of the corresponding sx9324_samp_freq_table[] entries.
+ */
 static const unsigned int sx9324_scan_period_table[] = {
-	2,   15,  30,  45,   60,   90,	 120,  200,
-	400, 600, 800, 1000, 2000, 3000, 4000, 5000,
+	1, 2, 4, 6, 8, 10, 14, 18,			/* 0x00 - 0x07 */
+	22, 26, 30, 34, 38, 42, 46, 50,			/* 0x08 - 0x0f */
+	56, 62, 68, 74, 80, 90, 100, 200,		/* 0x10 - 0x17 */
+	300, 400, 600, 800, 1000, 2000, 3000, 4000,	/* 0x18 - 0x1f */
 };
 
+static_assert(ARRAY_SIZE(sx9324_scan_period_table) == ARRAY_SIZE(sx9324_samp_freq_table));
+
 static const struct regmap_range sx9324_writable_reg_ranges[] = {
 	/*
 	 * To set COMPSTAT for compensation, even if datasheet says register is

base-commit: 2ef6f5c4ee56e90c237c5f7687f09e635f7d30a9
-- 
2.53.0

Re: [PATCH v2] iio: proximity: sx9324: fix out-of-bounds read of scan period table

[Jonathan Cameron]

On Sat, 24 Oct 2026 00:56:51 +0530
Arnav Kapoor <kapoorarnav43@gmail.com> wrote:

> The scan period of the SX9324 is selected by the 5 bit wide
> SX9324_REG_GNRL_CTRL0_SCANPERIOD field, so it has 32 possible values.
> sx9324_scan_period_table[] however only has 16 entries, it was copied
> over from the SX9310 driver where the field is only 4 bits wide.
> 
> sx9324_wait_for_sample() indexes the table with the raw field value, so
> all the codes from 16 to 31 read past the end of the array. The default
> value of the register is SX9324_REG_GNRL_CTRL0_SCANPERIOD_100MS (0x16,
> i.e. 22), so the out-of-bounds read happens with the default
> configuration of the device. It is only avoided when the device has an
> interrupt line, as the wait is only done in the polling case.
> 
> The value read is then used as the duration of an msleep() call, so the
> sensor is polled with a completely random delay.
> 
> Fill the table with the scan periods of all 32 codes, which are the
> periods documented for the corresponding sx9324_samp_freq_table[]
> entries, and add a static assertion to keep both tables in sync.
> 
> Fixes: 4c18a890dff8 ("iio:proximity:sx9324: Add SX9324 support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Arnav Kapoor <kapoorarnav43@gmail.com>
> ---
> Changes in v2:
> - Format sx9324_scan_period_table[] with a power-of-two number of entries
>   (8) per line and the register value range as a comment at the end of
>   each line, so the table is indexed and a typo is easy to find (Andy)
Looks good and matches what Andy asked about.

Applied to the fixes-togreg branch of iio.git.

thanks,

Jonathan

> - Put the static_assert() on a single line (Andy)
> - Add Fixes tag and Cc stable
> - Rebase on fixes-togreg
> 
> v1: https://lore.kernel.org/all/20261021225417.626946-1-kapoorarnav43@gmail.com/
> 
> Compile-tested only (W=1); I don't have SX9324 hardware.
> 
>  drivers/iio/proximity/sx9324.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/proximity/sx9324.c b/drivers/iio/proximity/sx9324.c
> index 255a36976ac4..43266a21bf2e 100644
> --- a/drivers/iio/proximity/sx9324.c
> +++ b/drivers/iio/proximity/sx9324.c
> @@ -279,11 +279,20 @@ static const struct {
>  	{ 0, 250000 },  /* 11111: 4 s */
>  };
>  
> +/*
> + * The scan period of the SX9324 is selected by the 5 bit wide
> + * SX9324_REG_GNRL_CTRL0_SCANPERIOD field. The values below are the scan
> + * periods in ms of the corresponding sx9324_samp_freq_table[] entries.
> + */
>  static const unsigned int sx9324_scan_period_table[] = {
> -	2,   15,  30,  45,   60,   90,	 120,  200,
> -	400, 600, 800, 1000, 2000, 3000, 4000, 5000,
> +	1, 2, 4, 6, 8, 10, 14, 18,			/* 0x00 - 0x07 */
> +	22, 26, 30, 34, 38, 42, 46, 50,			/* 0x08 - 0x0f */
> +	56, 62, 68, 74, 80, 90, 100, 200,		/* 0x10 - 0x17 */
> +	300, 400, 600, 800, 1000, 2000, 3000, 4000,	/* 0x18 - 0x1f */
>  };
>  
> +static_assert(ARRAY_SIZE(sx9324_scan_period_table) == ARRAY_SIZE(sx9324_samp_freq_table));
> +
>  static const struct regmap_range sx9324_writable_reg_ranges[] = {
>  	/*
>  	 * To set COMPSTAT for compensation, even if datasheet says register is
> 
> base-commit: 2ef6f5c4ee56e90c237c5f7687f09e635f7d30a9

Re: [PATCH v2] iio: proximity: sx9324: fix out-of-bounds read of scan period table

[Andy Shevchenko]

On Sat, Oct 24, 2026 at 12:56:51AM +0530, Arnav Kapoor wrote:
> The scan period of the SX9324 is selected by the 5 bit wide
> SX9324_REG_GNRL_CTRL0_SCANPERIOD field, so it has 32 possible values.
> sx9324_scan_period_table[] however only has 16 entries, it was copied
> over from the SX9310 driver where the field is only 4 bits wide.
> 
> sx9324_wait_for_sample() indexes the table with the raw field value, so
> all the codes from 16 to 31 read past the end of the array. The default
> value of the register is SX9324_REG_GNRL_CTRL0_SCANPERIOD_100MS (0x16,
> i.e. 22), so the out-of-bounds read happens with the default
> configuration of the device. It is only avoided when the device has an
> interrupt line, as the wait is only done in the polling case.
> 
> The value read is then used as the duration of an msleep() call, so the
> sensor is polled with a completely random delay.
> 
> Fill the table with the scan periods of all 32 codes, which are the
> periods documented for the corresponding sx9324_samp_freq_table[]
> entries, and add a static assertion to keep both tables in sync.

...

> +/*
> + * The scan period of the SX9324 is selected by the 5 bit wide

5-bit

> + * SX9324_REG_GNRL_CTRL0_SCANPERIOD field. The values below are the scan
> + * periods in ms of the corresponding sx9324_samp_freq_table[] entries.
> + */
>  static const unsigned int sx9324_scan_period_table[] = {
> -	2,   15,  30,  45,   60,   90,	 120,  200,
> -	400, 600, 800, 1000, 2000, 3000, 4000, 5000,
> +	1, 2, 4, 6, 8, 10, 14, 18,			/* 0x00 - 0x07 */
> +	22, 26, 30, 34, 38, 42, 46, 50,			/* 0x08 - 0x0f */
> +	56, 62, 68, 74, 80, 90, 100, 200,		/* 0x10 - 0x17 */
> +	300, 400, 600, 800, 1000, 2000, 3000, 4000,	/* 0x18 - 0x1f */
>  };

Haven't checked if this is part of any ABI. Otherwise LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko