--- /dev/null
+From 95ad67577de4ea08eb8e441394e698aa4addcc0b Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:37 +0100
+Subject: iio: accel: kxsd9: Fix alignment of local buffer.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 95ad67577de4ea08eb8e441394e698aa4addcc0b upstream.
+
+iio_push_to_buffers_with_timestamp assumes 8 byte alignment which
+is not guaranteed by an array of smaller elements.
+
+Note that whilst in this particular case the alignment forcing
+of the ts element is not strictly necessary it acts as good
+documentation. Doing this where not necessary should cut
+down on the number of cut and paste introduced errors elsewhere.
+
+Fixes: 0427a106a98a ("iio: accel: kxsd9: Add triggered buffer handling")
+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/accel/kxsd9.c | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/drivers/iio/accel/kxsd9.c
++++ b/drivers/iio/accel/kxsd9.c
+@@ -209,14 +209,20 @@ static irqreturn_t kxsd9_trigger_handler
+ const struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct kxsd9_state *st = iio_priv(indio_dev);
++ /*
++ * Ensure correct positioning and alignment of timestamp.
++ * No need to zero initialize as all elements written.
++ */
++ struct {
++ __be16 chan[4];
++ s64 ts __aligned(8);
++ } hw_values;
+ int ret;
+- /* 4 * 16bit values AND timestamp */
+- __be16 hw_values[8];
+
+ ret = regmap_bulk_read(st->map,
+ KXSD9_REG_X,
+- &hw_values,
+- 8);
++ hw_values.chan,
++ sizeof(hw_values.chan));
+ if (ret) {
+ dev_err(st->dev,
+ "error reading data\n");
+@@ -224,7 +230,7 @@ static irqreturn_t kxsd9_trigger_handler
+ }
+
+ iio_push_to_buffers_with_timestamp(indio_dev,
+- hw_values,
++ &hw_values,
+ iio_get_time_ns(indio_dev));
+ iio_trigger_notify_done(indio_dev->trig);
+
--- /dev/null
+From 7e5ac1f2206eda414f90c698fe1820dee873394d Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:40 +0100
+Subject: iio:accel:mma7455: Fix timestamp alignment and prevent data leak.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 7e5ac1f2206eda414f90c698fe1820dee873394d 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 u8 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.
+
+The force alignment of ts is not strictly necessary in this particularly
+case but does make the code less fragile.
+
+Fixes: a84ef0d181d9 ("iio: accel: add Freescale MMA7455L/MMA7456L 3-axis accelerometer driver")
+Reported-by: Lars-Peter Clausen <lars@metafoo.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/accel/mma7455_core.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/accel/mma7455_core.c
++++ b/drivers/iio/accel/mma7455_core.c
+@@ -52,6 +52,14 @@
+
+ struct mma7455_data {
+ struct regmap *regmap;
++ /*
++ * Used to reorganize data. Will ensure correct alignment of
++ * the timestamp if present
++ */
++ struct {
++ __le16 channels[3];
++ s64 ts __aligned(8);
++ } scan;
+ };
+
+ static int mma7455_drdy(struct mma7455_data *mma7455)
+@@ -82,19 +90,19 @@ static irqreturn_t mma7455_trigger_handl
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct mma7455_data *mma7455 = iio_priv(indio_dev);
+- u8 buf[16]; /* 3 x 16-bit channels + padding + ts */
+ int ret;
+
+ ret = mma7455_drdy(mma7455);
+ if (ret)
+ goto done;
+
+- ret = regmap_bulk_read(mma7455->regmap, MMA7455_REG_XOUTL, buf,
+- sizeof(__le16) * 3);
++ ret = regmap_bulk_read(mma7455->regmap, MMA7455_REG_XOUTL,
++ mma7455->scan.channels,
++ sizeof(mma7455->scan.channels));
+ if (ret)
+ goto done;
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buf,
++ iio_push_to_buffers_with_timestamp(indio_dev, &mma7455->scan,
+ iio_get_time_ns(indio_dev));
+
+ done:
--- /dev/null
+From 89226a296d816727405d3fea684ef69e7d388bd8 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:38 +0100
+Subject: iio:accel:mma8452: Fix timestamp alignment and prevent data leak.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 89226a296d816727405d3fea684ef69e7d388bd8 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 u8 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.
+
+The additional forcing of the 8 byte alignment of the timestamp
+is not strictly necessary but makes the code less fragile by
+making this explicit.
+
+Fixes: c7eeea93ac60 ("iio: Add Freescale MMA8452Q 3-axis accelerometer driver")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Cc: Peter Meerwald <pmeerw@pmeerw.net>
+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/accel/mma8452.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/accel/mma8452.c
++++ b/drivers/iio/accel/mma8452.c
+@@ -110,6 +110,12 @@ struct mma8452_data {
+ int sleep_val;
+ struct regulator *vdd_reg;
+ struct regulator *vddio_reg;
++
++ /* Ensure correct alignment of time stamp when present */
++ struct {
++ __be16 channels[3];
++ s64 ts __aligned(8);
++ } buffer;
+ };
+
+ /**
+@@ -1091,14 +1097,13 @@ static irqreturn_t mma8452_trigger_handl
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct mma8452_data *data = iio_priv(indio_dev);
+- u8 buffer[16]; /* 3 16-bit channels + padding + ts */
+ int ret;
+
+- ret = mma8452_read(data, (__be16 *)buffer);
++ ret = mma8452_read(data, data->buffer.channels);
+ if (ret < 0)
+ goto done;
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buffer,
++ iio_push_to_buffers_with_timestamp(indio_dev, &data->buffer,
+ iio_get_time_ns(indio_dev));
+
+ done:
--- /dev/null
+From 54f82df2ba86e2a8e9cbf4036d192366e3905c89 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:56 +0100
+Subject: iio:adc:ti-adc081c Fix alignment and data leak issues
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 54f82df2ba86e2a8e9cbf4036d192366e3905c89 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 eplicit alignment of ts is necessary to ensure correct padding
+on x86_32 where s64 is only aligned to 4 bytes.
+
+Fixes: 08e05d1fce5c ("ti-adc081c: Initial triggered buffer support")
+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/adc/ti-adc081c.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/adc/ti-adc081c.c
++++ b/drivers/iio/adc/ti-adc081c.c
+@@ -33,6 +33,12 @@ struct adc081c {
+
+ /* 8, 10 or 12 */
+ int bits;
++
++ /* Ensure natural alignment of buffer elements */
++ struct {
++ u16 channel;
++ s64 ts __aligned(8);
++ } scan;
+ };
+
+ #define REG_CONV_RES 0x00
+@@ -128,14 +134,13 @@ static irqreturn_t adc081c_trigger_handl
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct adc081c *data = iio_priv(indio_dev);
+- u16 buf[8]; /* 2 bytes data + 6 bytes padding + 8 bytes timestamp */
+ int ret;
+
+ ret = i2c_smbus_read_word_swapped(data->i2c, REG_CONV_RES);
+ if (ret < 0)
+ goto out;
+- buf[0] = ret;
+- iio_push_to_buffers_with_timestamp(indio_dev, buf,
++ data->scan.channel = ret;
++ iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
+ iio_get_time_ns(indio_dev));
+ out:
+ iio_trigger_notify_done(indio_dev->trig);
--- /dev/null
+From eb1a148ef41d8ae8d9201efc3f1b145976290331 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:43 +0100
+Subject: iio:chemical:ccs811: Fix timestamp alignment and prevent data leak.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit eb1a148ef41d8ae8d9201efc3f1b145976290331 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 with alignment
+explicitly requested. This data is allocated with kzalloc so no
+data can leak appart from previous readings.
+
+The explicit alignment of ts is necessary to ensure consistent
+padding for x86_32 in which the ts would otherwise be 4 byte aligned.
+
+Fixes: 283d26917ad6 ("iio: chemical: ccs811: Add triggered buffer support")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Cc: Narcisa Ana Maria Vasile <narcisaanamaria12@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/chemical/ccs811.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/chemical/ccs811.c
++++ b/drivers/iio/chemical/ccs811.c
+@@ -78,6 +78,11 @@ struct ccs811_data {
+ struct iio_trigger *drdy_trig;
+ struct gpio_desc *wakeup_gpio;
+ bool drdy_trig_on;
++ /* Ensures correct alignment of timestamp if present */
++ struct {
++ s16 channels[2];
++ s64 ts __aligned(8);
++ } scan;
+ };
+
+ static const struct iio_chan_spec ccs811_channels[] = {
+@@ -327,17 +332,17 @@ static irqreturn_t ccs811_trigger_handle
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct ccs811_data *data = iio_priv(indio_dev);
+ struct i2c_client *client = data->client;
+- s16 buf[8]; /* s16 eCO2 + s16 TVOC + padding + 8 byte timestamp */
+ int ret;
+
+- ret = i2c_smbus_read_i2c_block_data(client, CCS811_ALG_RESULT_DATA, 4,
+- (u8 *)&buf);
++ ret = i2c_smbus_read_i2c_block_data(client, CCS811_ALG_RESULT_DATA,
++ sizeof(data->scan.channels),
++ (u8 *)data->scan.channels);
+ if (ret != 4) {
+ dev_err(&client->dev, "cannot read sensor data\n");
+ goto err;
+ }
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buf,
++ iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
+ iio_get_time_ns(indio_dev));
+
+ err:
--- /dev/null
+From 523628852a5f5f34a15252b2634d0498d3cfb347 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:45 +0100
+Subject: iio:light:max44000 Fix timestamp alignment and prevent data leak.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 523628852a5f5f34a15252b2634d0498d3cfb347 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().
+This data is allocated with kzalloc so no data can leak appart
+from previous readings.
+
+It is necessary to force the alignment of ts to avoid the padding
+on x86_32 being different from 64 bit platorms (it alows for
+4 bytes aligned 8 byte types.
+
+Fixes: 06ad7ea10e2b ("max44000: Initial triggered buffer support")
+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/max44000.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/light/max44000.c
++++ b/drivers/iio/light/max44000.c
+@@ -75,6 +75,11 @@
+ struct max44000_data {
+ struct mutex lock;
+ struct regmap *regmap;
++ /* Ensure naturally aligned timestamp */
++ struct {
++ u16 channels[2];
++ s64 ts __aligned(8);
++ } scan;
+ };
+
+ /* Default scale is set to the minimum of 0.03125 or 1 / (1 << 5) lux */
+@@ -488,7 +493,6 @@ static irqreturn_t max44000_trigger_hand
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct max44000_data *data = iio_priv(indio_dev);
+- u16 buf[8]; /* 2x u16 + padding + 8 bytes timestamp */
+ int index = 0;
+ unsigned int regval;
+ int ret;
+@@ -498,17 +502,17 @@ static irqreturn_t max44000_trigger_hand
+ ret = max44000_read_alsval(data);
+ if (ret < 0)
+ goto out_unlock;
+- buf[index++] = ret;
++ data->scan.channels[index++] = ret;
+ }
+ if (test_bit(MAX44000_SCAN_INDEX_PRX, indio_dev->active_scan_mask)) {
+ ret = regmap_read(data->regmap, MAX44000_REG_PRX_DATA, ®val);
+ if (ret < 0)
+ goto out_unlock;
+- buf[index] = regval;
++ data->scan.channels[index] = regval;
+ }
+ mutex_unlock(&data->lock);
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buf,
++ iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
+ iio_get_time_ns(indio_dev));
+ iio_trigger_notify_done(indio_dev->trig);
+ return IRQ_HANDLED;
--- /dev/null
+From 02ad21cefbac4d89ac443866f25b90449527737b Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:49 +0100
+Subject: iio:magnetometer:ak8975 Fix alignment and data leak issues.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 02ad21cefbac4d89ac443866f25b90449527737b 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 as by
+coincidence the padding will end up the same, however I consider
+it to make the code less fragile and have included it.
+
+Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Cc: Gregor Boirie <gregor.boirie@parrot.com>
+Cc: Linus Walleij <linus.walleij@linaro.org>
+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/magnetometer/ak8975.c | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/drivers/iio/magnetometer/ak8975.c
++++ b/drivers/iio/magnetometer/ak8975.c
+@@ -365,6 +365,12 @@ struct ak8975_data {
+ struct iio_mount_matrix orientation;
+ struct regulator *vdd;
+ struct regulator *vid;
++
++ /* Ensure natural alignment of timestamp */
++ struct {
++ s16 channels[3];
++ s64 ts __aligned(8);
++ } scan;
+ };
+
+ /* Enable attached power regulator if any. */
+@@ -787,7 +793,6 @@ static void ak8975_fill_buffer(struct ii
+ const struct i2c_client *client = data->client;
+ const struct ak_def *def = data->def;
+ int ret;
+- s16 buff[8]; /* 3 x 16 bits axis values + 1 aligned 64 bits timestamp */
+ __le16 fval[3];
+
+ mutex_lock(&data->lock);
+@@ -810,12 +815,13 @@ static void ak8975_fill_buffer(struct ii
+ mutex_unlock(&data->lock);
+
+ /* Clamp to valid range. */
+- buff[0] = clamp_t(s16, le16_to_cpu(fval[0]), -def->range, def->range);
+- buff[1] = clamp_t(s16, le16_to_cpu(fval[1]), -def->range, def->range);
+- buff[2] = clamp_t(s16, le16_to_cpu(fval[2]), -def->range, def->range);
++ data->scan.channels[0] = clamp_t(s16, le16_to_cpu(fval[0]), -def->range, def->range);
++ data->scan.channels[1] = clamp_t(s16, le16_to_cpu(fval[1]), -def->range, def->range);
++ data->scan.channels[2] = clamp_t(s16, le16_to_cpu(fval[2]), -def->range, def->range);
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buff,
++ iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
+ iio_get_time_ns(indio_dev));
++
+ return;
+
+ unlock:
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
+iio-adc-ti-adc081c-fix-alignment-and-data-leak-issues.patch
+iio-magnetometer-ak8975-fix-alignment-and-data-leak-issues.patch
+iio-light-max44000-fix-timestamp-alignment-and-prevent-data-leak.patch
+iio-chemical-ccs811-fix-timestamp-alignment-and-prevent-data-leak.patch
+iio-accel-kxsd9-fix-alignment-of-local-buffer.patch
+iio-accel-mma7455-fix-timestamp-alignment-and-prevent-data-leak.patch
+iio-accel-mma8452-fix-timestamp-alignment-and-prevent-data-leak.patch
+staging-wlan-ng-fix-out-of-bounds-read-in-prism2sta_probe_usb.patch
--- /dev/null
+From fea22e159d51c766ba70473f473a0ec914cc7e92 Mon Sep 17 00:00:00 2001
+From: Rustam Kovhaev <rkovhaev@gmail.com>
+Date: Tue, 4 Aug 2020 07:56:14 -0700
+Subject: staging: wlan-ng: fix out of bounds read in prism2sta_probe_usb()
+
+From: Rustam Kovhaev <rkovhaev@gmail.com>
+
+commit fea22e159d51c766ba70473f473a0ec914cc7e92 upstream.
+
+let's use usb_find_common_endpoints() to discover endpoints, it does all
+necessary checks for type and xfer direction
+
+remove memset() in hfa384x_create(), because we now assign endpoints in
+prism2sta_probe_usb() and because create_wlan() uses kzalloc() to
+allocate hfa384x struct before calling hfa384x_create()
+
+Fixes: faaff9765664 ("staging: wlan-ng: properly check endpoint types")
+Reported-and-tested-by: syzbot+22794221ab96b0bab53a@syzkaller.appspotmail.com
+Link: https://syzkaller.appspot.com/bug?extid=22794221ab96b0bab53a
+Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200804145614.104320-1-rkovhaev@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/wlan-ng/hfa384x_usb.c | 5 -----
+ drivers/staging/wlan-ng/prism2usb.c | 19 ++++++-------------
+ 2 files changed, 6 insertions(+), 18 deletions(-)
+
+--- a/drivers/staging/wlan-ng/hfa384x_usb.c
++++ b/drivers/staging/wlan-ng/hfa384x_usb.c
+@@ -524,13 +524,8 @@ static void hfa384x_usb_defer(struct wor
+ */
+ void hfa384x_create(struct hfa384x *hw, struct usb_device *usb)
+ {
+- memset(hw, 0, sizeof(*hw));
+ hw->usb = usb;
+
+- /* set up the endpoints */
+- hw->endp_in = usb_rcvbulkpipe(usb, 1);
+- hw->endp_out = usb_sndbulkpipe(usb, 2);
+-
+ /* Set up the waitq */
+ init_waitqueue_head(&hw->cmdq);
+
+--- a/drivers/staging/wlan-ng/prism2usb.c
++++ b/drivers/staging/wlan-ng/prism2usb.c
+@@ -61,23 +61,14 @@ static int prism2sta_probe_usb(struct us
+ const struct usb_device_id *id)
+ {
+ struct usb_device *dev;
+- const struct usb_endpoint_descriptor *epd;
+- const struct usb_host_interface *iface_desc = interface->cur_altsetting;
++ struct usb_endpoint_descriptor *bulk_in, *bulk_out;
++ struct usb_host_interface *iface_desc = interface->cur_altsetting;
+ struct wlandevice *wlandev = NULL;
+ struct hfa384x *hw = NULL;
+ int result = 0;
+
+- if (iface_desc->desc.bNumEndpoints != 2) {
+- result = -ENODEV;
+- goto failed;
+- }
+-
+- result = -EINVAL;
+- epd = &iface_desc->endpoint[1].desc;
+- if (!usb_endpoint_is_bulk_in(epd))
+- goto failed;
+- epd = &iface_desc->endpoint[2].desc;
+- if (!usb_endpoint_is_bulk_out(epd))
++ result = usb_find_common_endpoints(iface_desc, &bulk_in, &bulk_out, NULL, NULL);
++ if (result)
+ goto failed;
+
+ dev = interface_to_usbdev(interface);
+@@ -96,6 +87,8 @@ static int prism2sta_probe_usb(struct us
+ }
+
+ /* Initialize the hw data */
++ hw->endp_in = usb_rcvbulkpipe(dev, bulk_in->bEndpointAddress);
++ hw->endp_out = usb_sndbulkpipe(dev, bulk_out->bEndpointAddress);
+ hfa384x_create(hw, dev);
+ hw->wlandev = wlandev;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
