--- /dev/null
+From foo@baz Wed Jan 6 07:10:48 PM CET 2021
+From: sayli karnik <karniksayli1995@gmail.com>
+Date: Tue, 11 Oct 2016 17:07:21 +0530
+Subject: iio: bmi160_core: Fix sparse warning due to incorrect type in assignment
+
+From: sayli karnik <karniksayli1995@gmail.com>
+
+commit dd4ba3fb22233e69f06399ee0aa7ecb11d2b595c upstream
+
+There is a type mismatch between the buffer which is of type s16 and the
+samples stored, which are declared as __le16.
+
+Fix the following sparse warning:
+drivers/iio/imu/bmi160/bmi160_core.c:411:26: warning: incorrect type
+in assignment (different base types)
+
+drivers/iio/imu/bmi160/bmi160_core.c:411:26: expected signed short
+[signed] [short] [explicitly-signed] <noident>
+drivers/iio/imu/bmi160/bmi160_core.c:411:26: got restricted __le16
+[addressable] [usertype] sample
+
+This is a cosmetic-type patch since it does not alter code behaviour.
+The le16 is going into a 16bit buf element, and is labelled as IIO_LE in the
+channel buffer definition.
+
+Signed-off-by: sayli karnik <karniksayli1995@gmail.com>
+Signed-off-by: Jonathan Cameron <jic23@kernel.org>
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/bmi160/bmi160_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/iio/imu/bmi160/bmi160_core.c
++++ b/drivers/iio/imu/bmi160/bmi160_core.c
+@@ -385,7 +385,8 @@ static irqreturn_t bmi160_trigger_handle
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct bmi160_data *data = iio_priv(indio_dev);
+- s16 buf[16]; /* 3 sens x 3 axis x s16 + 3 x s16 pad + 4 x s16 tstamp */
++ __le16 buf[16];
++ /* 3 sens x 3 axis x __le16 + 3 x __le16 pad + 4 x __le16 tstamp */
+ int i, ret, j = 0, base = BMI160_REG_DATA_MAGN_XOUT_L;
+ __le16 sample;
+
--- /dev/null
+From foo@baz Wed Jan 6 07:10:48 PM CET 2021
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Sun, 20 Sep 2020 12:27:39 +0100
+Subject: iio:imu:bmi160: Fix alignment and data leak issues
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 7b6b51234df6cd8b04fe736b0b89c25612d896b8 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 array in the iio_priv() data with alignment
+explicitly requested. This data is allocated with kzalloc() so no
+data can leak apart from previous readings.
+
+In this driver, depending on which channels are enabled, the timestamp
+can be in a number of locations. Hence we cannot use a structure
+to specify the data layout without it being misleading.
+
+Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Cc: Daniel Baluta <daniel.baluta@gmail.com>
+Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org
+[sudip: adjust context and use bmi160_data in old location]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/bmi160/bmi160_core.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/imu/bmi160/bmi160_core.c
++++ b/drivers/iio/imu/bmi160/bmi160_core.c
+@@ -110,6 +110,13 @@ enum bmi160_sensor_type {
+
+ struct bmi160_data {
+ struct regmap *regmap;
++ /*
++ * Ensure natural alignment for timestamp if present.
++ * Max length needed: 2 * 3 channels + 4 bytes padding + 8 byte ts.
++ * If fewer channels are enabled, less space may be needed, as
++ * long as the timestamp is still aligned to 8 bytes.
++ */
++ __le16 buf[12] __aligned(8);
+ };
+
+ const struct regmap_config bmi160_regmap_config = {
+@@ -385,8 +392,6 @@ static irqreturn_t bmi160_trigger_handle
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct bmi160_data *data = iio_priv(indio_dev);
+- __le16 buf[12];
+- /* 2 sens x 3 axis x __le16 + 2 x __le16 pad + 4 x __le16 tstamp */
+ int i, ret, j = 0, base = BMI160_REG_DATA_MAGN_XOUT_L;
+ __le16 sample;
+
+@@ -396,10 +401,10 @@ static irqreturn_t bmi160_trigger_handle
+ &sample, sizeof(__le16));
+ if (ret < 0)
+ goto done;
+- buf[j++] = sample;
++ data->buf[j++] = sample;
+ }
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buf,
++ iio_push_to_buffers_with_timestamp(indio_dev, data->buf,
+ iio_get_time_ns(indio_dev));
+ done:
+ iio_trigger_notify_done(indio_dev->trig);
--- /dev/null
+From foo@baz Wed Jan 6 07:10:48 PM CET 2021
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Sun, 20 Sep 2020 12:27:38 +0100
+Subject: iio:imu:bmi160: Fix too large a buffer.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit dc7de42d6b50a07b37feeba4c6b5136290fcee81 upstream.
+
+The comment implies this device has 3 sensor types, but it only
+has an accelerometer and a gyroscope (both 3D). As such the
+buffer does not need to be as long as stated.
+
+Note I've separated this from the following patch which fixes
+the alignment for passing to iio_push_to_buffers_with_timestamp()
+as they are different issues even if they affect the same line
+of code.
+
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200920112742.170751-5-jic23@kernel.org
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/bmi160/bmi160_core.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/imu/bmi160/bmi160_core.c
++++ b/drivers/iio/imu/bmi160/bmi160_core.c
+@@ -385,8 +385,8 @@ static irqreturn_t bmi160_trigger_handle
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct bmi160_data *data = iio_priv(indio_dev);
+- __le16 buf[16];
+- /* 3 sens x 3 axis x __le16 + 3 x __le16 pad + 4 x __le16 tstamp */
++ __le16 buf[12];
++ /* 2 sens x 3 axis x __le16 + 2 x __le16 pad + 4 x __le16 tstamp */
+ int i, ret, j = 0, base = BMI160_REG_DATA_MAGN_XOUT_L;
+ __le16 sample;
+
--- /dev/null
+From foo@baz Wed Jan 6 07:12:39 PM CET 2021
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Sun, 20 Sep 2020 12:27:37 +0100
+Subject: iio:magnetometer:mag3110: Fix alignment and data leak issues.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 89deb1334252ea4a8491d47654811e28b0790364 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 not necessary in this case but
+does make the code slightly less fragile so I have included it.
+
+Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
+[sudip: adjust context]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/magnetometer/mag3110.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/magnetometer/mag3110.c
++++ b/drivers/iio/magnetometer/mag3110.c
+@@ -52,6 +52,12 @@ struct mag3110_data {
+ struct i2c_client *client;
+ struct mutex lock;
+ u8 ctrl_reg1;
++ /* Ensure natural alignment of timestamp */
++ struct {
++ __be16 channels[3];
++ u8 temperature;
++ s64 ts __aligned(8);
++ } scan;
+ };
+
+ static int mag3110_request(struct mag3110_data *data)
+@@ -262,10 +268,9 @@ static irqreturn_t mag3110_trigger_handl
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct mag3110_data *data = iio_priv(indio_dev);
+- u8 buffer[16]; /* 3 16-bit channels + 1 byte temp + padding + ts */
+ int ret;
+
+- ret = mag3110_read(data, (__be16 *) buffer);
++ ret = mag3110_read(data, data->scan.channels);
+ if (ret < 0)
+ goto done;
+
+@@ -274,10 +279,10 @@ static irqreturn_t mag3110_trigger_handl
+ MAG3110_DIE_TEMP);
+ if (ret < 0)
+ goto done;
+- buffer[6] = ret;
++ data->scan.temperature = ret;
+ }
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buffer,
++ iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
+ iio_get_time_ns(indio_dev));
+
+ done:
xen-xenbus-xen_bus_type-support-will_handle-watch-callback.patch
xen-xenbus-count-pending-messages-for-each-watch.patch
xenbus-xenbus_backend-disallow-pending-watch-messages.patch
+iio-bmi160_core-fix-sparse-warning-due-to-incorrect-type-in-assignment.patch
+iio-imu-bmi160-fix-too-large-a-buffer.patch
+iio-imu-bmi160-fix-alignment-and-data-leak-issues.patch
+iio-magnetometer-mag3110-fix-alignment-and-data-leak-issues.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
