--- /dev/null
+From a6f86f724394de3629da63fe5e1b7a4ab3396efe Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:39 +0100
+Subject: iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit a6f86f724394de3629da63fe5e1b7a4ab3396efe upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses a 16 byte array of smaller elements on the stack.
+As Lars also noted this anti pattern can involve a leak of data to
+userspace and that indeed can happen here. We close both issues by moving
+to a suitable structure in the iio_priv() data with alignment
+ensured by use of an explicit c structure. This data is allocated
+with kzalloc so no data can leak appart from previous readings.
+
+Fixes tag is beyond some major refactoring so likely manual backporting
+would be needed to get that far back.
+
+Whilst the force alignment of the ts is not strictly necessary, it
+does make the code less fragile.
+
+Fixes: 3bbec9773389 ("iio: bmc150_accel: add support for hardware fifo")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/accel/bmc150-accel-core.c | 15 ++++++++++++---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/accel/bmc150-accel-core.c
++++ b/drivers/iio/accel/bmc150-accel-core.c
+@@ -189,6 +189,14 @@ struct bmc150_accel_data {
+ struct mutex mutex;
+ u8 fifo_mode, watermark;
+ s16 buffer[8];
++ /*
++ * Ensure there is sufficient space and correct alignment for
++ * the timestamp if enabled
++ */
++ struct {
++ __le16 channels[3];
++ s64 ts __aligned(8);
++ } scan;
+ u8 bw_bits;
+ u32 slope_dur;
+ u32 slope_thres;
+@@ -922,15 +930,16 @@ static int __bmc150_accel_fifo_flush(str
+ * now.
+ */
+ for (i = 0; i < count; i++) {
+- u16 sample[8];
+ int j, bit;
+
+ j = 0;
+ for_each_set_bit(bit, indio_dev->active_scan_mask,
+ indio_dev->masklength)
+- memcpy(&sample[j++], &buffer[i * 3 + bit], 2);
++ memcpy(&data->scan.channels[j++], &buffer[i * 3 + bit],
++ sizeof(data->scan.channels[0]));
+
+- iio_push_to_buffers_with_timestamp(indio_dev, sample, tstamp);
++ iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
++ tstamp);
+
+ tstamp += sample_period;
+ }
--- /dev/null
+From f8cd222feb82ecd82dcf610fcc15186f55f9c2b5 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:51:02 +0100
+Subject: iio:adc:ina2xx Fix timestamp alignment issue.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit f8cd222feb82ecd82dcf610fcc15186f55f9c2b5 upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses a 32 byte array of smaller elements on the stack.
+As Lars also noted this anti pattern can involve a leak of data to
+userspace and that indeed can happen here. We close both issues by
+moving to a suitable structure in the iio_priv() data with alignment
+explicitly requested. This data is allocated with kzalloc so no
+data can leak apart from previous readings. The explicit alignment
+isn't technically needed here, but it reduced fragility and avoids
+cut and paste into drivers where it will be needed.
+
+If we want this in older stables will need manual backport due to
+driver reworks.
+
+Fixes: c43a102e67db ("iio: ina2xx: add support for TI INA2xx Power Monitors")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Cc: Stefan Brüns <stefan.bruens@rwth-aachen.de>
+Cc: Marc Titinger <mtitinger@baylibre.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/ina2xx-adc.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/adc/ina2xx-adc.c
++++ b/drivers/iio/adc/ina2xx-adc.c
+@@ -146,6 +146,11 @@ struct ina2xx_chip_info {
+ int range_vbus; /* Bus voltage maximum in V */
+ int pga_gain_vshunt; /* Shunt voltage PGA gain */
+ bool allow_async_readout;
++ /* data buffer needs space for channel data and timestamp */
++ struct {
++ u16 chan[4];
++ u64 ts __aligned(8);
++ } scan;
+ };
+
+ static const struct ina2xx_config ina2xx_config[] = {
+@@ -738,8 +743,6 @@ static int ina2xx_conversion_ready(struc
+ static int ina2xx_work_buffer(struct iio_dev *indio_dev)
+ {
+ struct ina2xx_chip_info *chip = iio_priv(indio_dev);
+- /* data buffer needs space for channel data and timestap */
+- unsigned short data[4 + sizeof(s64)/sizeof(short)];
+ int bit, ret, i = 0;
+ s64 time;
+
+@@ -758,10 +761,10 @@ static int ina2xx_work_buffer(struct iio
+ if (ret < 0)
+ return ret;
+
+- data[i++] = val;
++ chip->scan.chan[i++] = val;
+ }
+
+- iio_push_to_buffers_with_timestamp(indio_dev, data, time);
++ iio_push_to_buffers_with_timestamp(indio_dev, &chip->scan, time);
+
+ return 0;
+ };
--- /dev/null
+From db8f06d97ec284dc018e2e4890d2e5035fde8630 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:51:03 +0100
+Subject: iio:adc:max1118 Fix alignment of timestamp and data leak issues
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit db8f06d97ec284dc018e2e4890d2e5035fde8630 upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses an array of smaller elements on the stack.
+As Lars also noted this anti pattern can involve a leak of data to
+userspace and that indeed can happen here. We close both issues by
+moving to a suitable structure in the iio_priv() data.
+
+This data is allocated with kzalloc so no data can leak apart
+from previous readings.
+
+The explicit alignment of ts is necessary to ensure correct padding
+on architectures where s64 is only 4 bytes aligned such as x86_32.
+
+Fixes: a9e9c7153e96 ("iio: adc: add max1117/max1118/max1119 ADC driver")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Cc: Akinobu Mita <akinobu.mita@gmail.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/max1118.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/adc/max1118.c
++++ b/drivers/iio/adc/max1118.c
+@@ -35,6 +35,11 @@ struct max1118 {
+ struct spi_device *spi;
+ struct mutex lock;
+ struct regulator *reg;
++ /* Ensure natural alignment of buffer elements */
++ struct {
++ u8 channels[2];
++ s64 ts __aligned(8);
++ } scan;
+
+ u8 data ____cacheline_aligned;
+ };
+@@ -165,7 +170,6 @@ static irqreturn_t max1118_trigger_handl
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct max1118 *adc = iio_priv(indio_dev);
+- u8 data[16] = { }; /* 2x 8-bit ADC data + padding + 8 bytes timestamp */
+ int scan_index;
+ int i = 0;
+
+@@ -183,10 +187,10 @@ static irqreturn_t max1118_trigger_handl
+ goto out;
+ }
+
+- data[i] = ret;
++ adc->scan.channels[i] = ret;
+ i++;
+ }
+- iio_push_to_buffers_with_timestamp(indio_dev, data,
++ iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan,
+ iio_get_time_ns(indio_dev));
+ out:
+ mutex_unlock(&adc->lock);
--- /dev/null
+From 3f1093d83d7164e4705e4232ccf76da54adfda85 Mon Sep 17 00:00:00 2001
+From: Angelo Compagnucci <angelo.compagnucci@gmail.com>
+Date: Wed, 19 Aug 2020 09:55:25 +0200
+Subject: iio: adc: mcp3422: fix locking scope
+
+From: Angelo Compagnucci <angelo.compagnucci@gmail.com>
+
+commit 3f1093d83d7164e4705e4232ccf76da54adfda85 upstream.
+
+Locking should be held for the entire reading sequence involving setting
+the channel, waiting for the channel switch and reading from the
+channel.
+If not, reading from a channel can result mixing with the reading from
+another channel.
+
+Fixes: 07914c84ba30 ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC")
+Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
+Link: https://lore.kernel.org/r/20200819075525.1395248-1-angelo.compagnucci@gmail.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/mcp3422.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/iio/adc/mcp3422.c
++++ b/drivers/iio/adc/mcp3422.c
+@@ -96,16 +96,12 @@ static int mcp3422_update_config(struct
+ {
+ int ret;
+
+- mutex_lock(&adc->lock);
+-
+ ret = i2c_master_send(adc->i2c, &newconfig, 1);
+ if (ret > 0) {
+ adc->config = newconfig;
+ ret = 0;
+ }
+
+- mutex_unlock(&adc->lock);
+-
+ return ret;
+ }
+
+@@ -138,6 +134,8 @@ static int mcp3422_read_channel(struct m
+ u8 config;
+ u8 req_channel = channel->channel;
+
++ mutex_lock(&adc->lock);
++
+ if (req_channel != MCP3422_CHANNEL(adc->config)) {
+ config = adc->config;
+ config &= ~MCP3422_CHANNEL_MASK;
+@@ -152,7 +150,11 @@ static int mcp3422_read_channel(struct m
+ msleep(mcp3422_read_times[MCP3422_SAMPLE_RATE(adc->config)]);
+ }
+
+- return mcp3422_read(adc, value, &config);
++ ret = mcp3422_read(adc, value, &config);
++
++ mutex_unlock(&adc->lock);
++
++ return ret;
+ }
+
+ static int mcp3422_read_raw(struct iio_dev *iio,
--- /dev/null
+From a661b571e3682705cb402a5cd1e970586a3ec00f Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:57 +0100
+Subject: iio:adc:ti-adc084s021 Fix alignment and data leak issues.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit a661b571e3682705cb402a5cd1e970586a3ec00f upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses an array of smaller elements on the stack.
+As Lars also noted this anti pattern can involve a leak of data to
+userspace and that indeed can happen here. We close both issues by
+moving to a suitable structure in the iio_priv().
+
+This data is allocated with kzalloc so no data can leak apart from
+previous readings.
+
+The force alignment of ts is not strictly necessary in this case
+but reduces the fragility of the code.
+
+Fixes: 3691e5a69449 ("iio: adc: add driver for the ti-adc084s021 chip")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Cc: Mårten Lindahl <martenli@axis.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/ti-adc084s021.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/adc/ti-adc084s021.c
++++ b/drivers/iio/adc/ti-adc084s021.c
+@@ -25,6 +25,11 @@ struct adc084s021 {
+ struct spi_transfer spi_trans;
+ struct regulator *reg;
+ struct mutex lock;
++ /* Buffer used to align data */
++ struct {
++ __be16 channels[4];
++ s64 ts __aligned(8);
++ } scan;
+ /*
+ * DMA (thus cache coherency maintenance) requires the
+ * transfer buffers to live in their own cache line.
+@@ -140,14 +145,13 @@ static irqreturn_t adc084s021_buffer_tri
+ struct iio_poll_func *pf = pollfunc;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct adc084s021 *adc = iio_priv(indio_dev);
+- __be16 data[8] = {0}; /* 4 * 16-bit words of data + 8 bytes timestamp */
+
+ mutex_lock(&adc->lock);
+
+- if (adc084s021_adc_conversion(adc, &data) < 0)
++ if (adc084s021_adc_conversion(adc, adc->scan.channels) < 0)
+ dev_err(&adc->spi->dev, "Failed to read data\n");
+
+- iio_push_to_buffers_with_timestamp(indio_dev, data,
++ iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan,
+ iio_get_time_ns(indio_dev));
+ mutex_unlock(&adc->lock);
+ iio_trigger_notify_done(indio_dev->trig);
--- /dev/null
+From e71e6dbe96ac80ac2aebe71a6a942e7bd60e7596 Mon Sep 17 00:00:00 2001
+From: Maxim Kochetkov <fido_max@inbox.ru>
+Date: Mon, 3 Aug 2020 08:04:05 +0300
+Subject: iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set
+
+From: Maxim Kochetkov <fido_max@inbox.ru>
+
+commit e71e6dbe96ac80ac2aebe71a6a942e7bd60e7596 upstream.
+
+To stop conversion ads1015_set_power_state() function call unimplemented
+function __pm_runtime_suspend() from pm_runtime_put_autosuspend()
+if CONFIG_PM is not set.
+In case of CONFIG_PM is not set: __pm_runtime_suspend() returns -ENOSYS,
+so ads1015_read_raw() failed because ads1015_set_power_state() returns an
+error.
+
+If CONFIG_PM is disabled, there is no need to start/stop conversion.
+Fix it by adding return 0 function variant if CONFIG_PM is not set.
+
+Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
+Fixes: ecc24e72f437 ("iio: adc: Add TI ADS1015 ADC driver support")
+Tested-by: Maxim Kiselev <bigunclemax@gmail.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/ti-ads1015.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/iio/adc/ti-ads1015.c
++++ b/drivers/iio/adc/ti-ads1015.c
+@@ -316,6 +316,7 @@ static const struct iio_chan_spec ads111
+ IIO_CHAN_SOFT_TIMESTAMP(ADS1015_TIMESTAMP),
+ };
+
++#ifdef CONFIG_PM
+ static int ads1015_set_power_state(struct ads1015_data *data, bool on)
+ {
+ int ret;
+@@ -333,6 +334,15 @@ static int ads1015_set_power_state(struc
+ return ret < 0 ? ret : 0;
+ }
+
++#else /* !CONFIG_PM */
++
++static int ads1015_set_power_state(struct ads1015_data *data, bool on)
++{
++ return 0;
++}
++
++#endif /* !CONFIG_PM */
++
+ static
+ int ads1015_get_adc_result(struct ads1015_data *data, int chan, int *val)
+ {
--- /dev/null
+From 336306790b2bbf7ce837625fa3b24ba724d05838 Mon Sep 17 00:00:00 2001
+From: Gwendal Grignou <gwendal@chromium.org>
+Date: Tue, 28 Jul 2020 13:48:25 -0700
+Subject: iio: cros_ec: Set Gyroscope default frequency to 25Hz
+
+From: Gwendal Grignou <gwendal@chromium.org>
+
+commit 336306790b2bbf7ce837625fa3b24ba724d05838 upstream.
+
+BMI160 Minimium gyroscope frequency in normal mode is 25Hz.
+When older EC firmware do not report their sensors frequencies,
+use 25Hz as the minimum for gyroscope to be sure it works on BMI160.
+
+Fixes: ae7b02ad2f32d ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
+Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
+Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
++++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+@@ -72,10 +72,13 @@ static void get_default_min_max_freq(enu
+
+ switch (type) {
+ case MOTIONSENSE_TYPE_ACCEL:
+- case MOTIONSENSE_TYPE_GYRO:
+ *min_freq = 12500;
+ *max_freq = 100000;
+ break;
++ case MOTIONSENSE_TYPE_GYRO:
++ *min_freq = 25000;
++ *max_freq = 100000;
++ break;
+ case MOTIONSENSE_TYPE_MAG:
+ *min_freq = 5000;
+ *max_freq = 25000;
--- /dev/null
+From 2684d5003490df5398aeafe2592ba9d4a4653998 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:48 +0100
+Subject: iio:light:ltr501 Fix timestamp alignment issue.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 2684d5003490df5398aeafe2592ba9d4a4653998 upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses an array of smaller elements on the stack.
+Here we use a structure on the stack. The driver already did an
+explicit memset so no data leak was possible.
+
+Forced alignment of ts is not strictly necessary but probably makes
+the code slightly less fragile.
+
+Note there has been some rework in this driver of the years, so no
+way this will apply cleanly all the way back.
+
+Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/light/ltr501.c | 15 +++++++++------
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+--- a/drivers/iio/light/ltr501.c
++++ b/drivers/iio/light/ltr501.c
+@@ -1243,13 +1243,16 @@ static irqreturn_t ltr501_trigger_handle
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct ltr501_data *data = iio_priv(indio_dev);
+- u16 buf[8];
++ struct {
++ u16 channels[3];
++ s64 ts __aligned(8);
++ } scan;
+ __le16 als_buf[2];
+ u8 mask = 0;
+ int j = 0;
+ int ret, psdata;
+
+- memset(buf, 0, sizeof(buf));
++ memset(&scan, 0, sizeof(scan));
+
+ /* figure out which data needs to be ready */
+ if (test_bit(0, indio_dev->active_scan_mask) ||
+@@ -1268,9 +1271,9 @@ static irqreturn_t ltr501_trigger_handle
+ if (ret < 0)
+ return ret;
+ if (test_bit(0, indio_dev->active_scan_mask))
+- buf[j++] = le16_to_cpu(als_buf[1]);
++ scan.channels[j++] = le16_to_cpu(als_buf[1]);
+ if (test_bit(1, indio_dev->active_scan_mask))
+- buf[j++] = le16_to_cpu(als_buf[0]);
++ scan.channels[j++] = le16_to_cpu(als_buf[0]);
+ }
+
+ if (mask & LTR501_STATUS_PS_RDY) {
+@@ -1278,10 +1281,10 @@ static irqreturn_t ltr501_trigger_handle
+ &psdata, 2);
+ if (ret < 0)
+ goto done;
+- buf[j++] = psdata & LTR501_PS_DATA_MASK;
++ scan.channels[j++] = psdata & LTR501_PS_DATA_MASK;
+ }
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buf,
++ iio_push_to_buffers_with_timestamp(indio_dev, &scan,
+ iio_get_time_ns(indio_dev));
+
+ done:
--- /dev/null
+From f60e8bb84282b8e633956cfe74b4f0d64ca73cec Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:42 +0100
+Subject: iio:proximity:mb1232: Fix timestamp alignment and prevent data leak.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit f60e8bb84282b8e633956cfe74b4f0d64ca73cec upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses a 16 byte s16 array on the stack As Lars also noted
+this anti pattern can involve a leak of data to userspace and that
+indeed can happen here. We close both issues by moving to
+a suitable structure in the iio_priv() data with alignment
+ensured by use of an explicit c structure. This data is allocated
+with kzalloc so no data can leak appart from previous readings.
+
+In this case the forced alignment of the ts is necessary to ensure
+correct padding on x86_32 where the s64 would only be 4 byte aligned.
+
+Fixes: 16b05261537e ("mb1232.c: add distance iio sensor with i2c")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Cc: Andreas Klinger <ak@it-klinger.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Cc: <Stable@vger.kernel.org>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/proximity/mb1232.c | 17 +++++++++--------
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+--- a/drivers/iio/proximity/mb1232.c
++++ b/drivers/iio/proximity/mb1232.c
+@@ -40,6 +40,11 @@ struct mb1232_data {
+ */
+ struct completion ranging;
+ int irqnr;
++ /* Ensure correct alignment of data to push to IIO buffer */
++ struct {
++ s16 distance;
++ s64 ts __aligned(8);
++ } scan;
+ };
+
+ static irqreturn_t mb1232_handle_irq(int irq, void *dev_id)
+@@ -113,17 +118,13 @@ static irqreturn_t mb1232_trigger_handle
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct mb1232_data *data = iio_priv(indio_dev);
+- /*
+- * triggered buffer
+- * 16-bit channel + 48-bit padding + 64-bit timestamp
+- */
+- s16 buffer[8] = { 0 };
+
+- buffer[0] = mb1232_read_distance(data);
+- if (buffer[0] < 0)
++ data->scan.distance = mb1232_read_distance(data);
++ if (data->scan.distance < 0)
+ goto err;
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buffer, pf->timestamp);
++ iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
++ pf->timestamp);
+
+ err:
+ iio_trigger_notify_done(indio_dev->trig);
iommu-amd-do-not-force-direct-mapping-when-sme-is-ac.patch
iommu-amd-do-not-use-iommuv2-functionality-when-sme-.patch
gcov-disable-gcov-build-with-gcc-10.patch
+iio-adc-mcp3422-fix-locking-scope.patch
+iio-adc-ti-ads1015-fix-conversion-when-config_pm-is-not-set.patch
+iio-cros_ec-set-gyroscope-default-frequency-to-25hz.patch
+iio-light-ltr501-fix-timestamp-alignment-issue.patch
+iio-proximity-mb1232-fix-timestamp-alignment-and-prevent-data-leak.patch
+iio-accel-bmc150-accel-fix-timestamp-alignment-and-prevent-data-leak.patch
+iio-adc-ti-adc084s021-fix-alignment-and-data-leak-issues.patch
+iio-adc-ina2xx-fix-timestamp-alignment-issue.patch
+iio-adc-max1118-fix-alignment-of-timestamp-and-data-leak-issues.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
