--- /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
+@@ -198,6 +198,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;
+@@ -924,15 +932,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 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
+@@ -98,16 +98,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;
+ }
+
+@@ -140,6 +136,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;
+@@ -154,7 +152,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 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
+@@ -1218,13 +1218,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) ||
+@@ -1243,9 +1246,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) {
+@@ -1253,10 +1256,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_get_time_ns());
++ iio_push_to_buffers_with_timestamp(indio_dev, &scan, iio_get_time_ns());
+
+ done:
+ iio_trigger_notify_done(indio_dev->trig);
drivers-net-wan-hdlc_cisco-add-hard_header_len.patch
alsa-hda-fix-a-runtime-pm-issue-in-sof-when-integrat.patch
gcov-disable-gcov-build-with-gcc-10.patch
+iio-adc-mcp3422-fix-locking-scope.patch
+iio-light-ltr501-fix-timestamp-alignment-issue.patch
+iio-accel-bmc150-accel-fix-timestamp-alignment-and-prevent-data-leak.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
