--- /dev/null
+From 2a3f7221acddfe1caa9ff09b3a8158c39b2fdeac Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 16 Apr 2019 17:06:33 +0200
+Subject: ALSA: core: Fix card races between register and disconnect
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 2a3f7221acddfe1caa9ff09b3a8158c39b2fdeac upstream.
+
+There is a small race window in the card disconnection code that
+allows the registration of another card with the very same card id.
+This leads to a warning in procfs creation as caught by syzkaller.
+
+The problem is that we delete snd_cards and snd_cards_lock entries at
+the very beginning of the disconnection procedure. This makes the
+slot available to be assigned for another card object while the
+disconnection procedure is being processed. Then it becomes possible
+to issue a procfs registration with the existing file name although we
+check the conflict beforehand.
+
+The fix is simply to move the snd_cards and snd_cards_lock clearances
+at the end of the disconnection procedure. The references to these
+entries are merely either from the global proc files like
+/proc/asound/cards or from the card registration / disconnection, so
+it should be fine to shift at the very end.
+
+Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/init.c | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/sound/core/init.c
++++ b/sound/core/init.c
+@@ -405,14 +405,7 @@ int snd_card_disconnect(struct snd_card
+ card->shutdown = 1;
+ spin_unlock(&card->files_lock);
+
+- /* phase 1: disable fops (user space) operations for ALSA API */
+- mutex_lock(&snd_card_mutex);
+- snd_cards[card->number] = NULL;
+- clear_bit(card->number, snd_cards_lock);
+- mutex_unlock(&snd_card_mutex);
+-
+- /* phase 2: replace file->f_op with special dummy operations */
+-
++ /* replace file->f_op with special dummy operations */
+ spin_lock(&card->files_lock);
+ list_for_each_entry(mfile, &card->files_list, list) {
+ /* it's critical part, use endless loop */
+@@ -428,7 +421,7 @@ int snd_card_disconnect(struct snd_card
+ }
+ spin_unlock(&card->files_lock);
+
+- /* phase 3: notify all connected devices about disconnection */
++ /* notify all connected devices about disconnection */
+ /* at this point, they cannot respond to any calls except release() */
+
+ #if IS_ENABLED(CONFIG_SND_MIXER_OSS)
+@@ -444,6 +437,13 @@ int snd_card_disconnect(struct snd_card
+ device_del(&card->card_dev);
+ card->registered = false;
+ }
++
++ /* disable fops (user space) operations for ALSA API */
++ mutex_lock(&snd_card_mutex);
++ snd_cards[card->number] = NULL;
++ clear_bit(card->number, snd_cards_lock);
++ mutex_unlock(&snd_card_mutex);
++
+ #ifdef CONFIG_PM
+ wake_up(&card->power_sleep);
+ #endif
--- /dev/null
+From ff8acf929014b7f87315588e0daf8597c8aa9d1c Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Wed, 17 Apr 2019 00:21:21 -0700
+Subject: arm64: futex: Restore oldval initialization to work around buggy compilers
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+commit ff8acf929014b7f87315588e0daf8597c8aa9d1c upstream.
+
+Commit 045afc24124d ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with
+non-zero result value") removed oldval's zero initialization in
+arch_futex_atomic_op_inuser because it is not necessary. Unfortunately,
+Android's arm64 GCC 4.9.4 [1] does not agree:
+
+../kernel/futex.c: In function 'do_futex':
+../kernel/futex.c:1658:17: warning: 'oldval' may be used uninitialized
+in this function [-Wmaybe-uninitialized]
+ return oldval == cmparg;
+ ^
+In file included from ../kernel/futex.c:73:0:
+../arch/arm64/include/asm/futex.h:53:6: note: 'oldval' was declared here
+ int oldval, ret, tmp;
+ ^
+
+GCC fails to follow that when ret is non-zero, futex_atomic_op_inuser
+returns right away, avoiding the uninitialized use that it claims.
+Restoring the zero initialization works around this issue.
+
+[1]: https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
+
+Cc: stable@vger.kernel.org
+Fixes: 045afc24124d ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value")
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/futex.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/include/asm/futex.h
++++ b/arch/arm64/include/asm/futex.h
+@@ -55,7 +55,7 @@
+ static inline int
+ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
+ {
+- int oldval, ret, tmp;
++ int oldval = 0, ret, tmp;
+
+ pagefault_disable();
+
--- /dev/null
+From 678cce4019d746da6c680c48ba9e6d417803e127 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Sun, 31 Mar 2019 13:04:11 -0700
+Subject: crypto: x86/poly1305 - fix overflow during partial reduction
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 678cce4019d746da6c680c48ba9e6d417803e127 upstream.
+
+The x86_64 implementation of Poly1305 produces the wrong result on some
+inputs because poly1305_4block_avx2() incorrectly assumes that when
+partially reducing the accumulator, the bits carried from limb 'd4' to
+limb 'h0' fit in a 32-bit integer. This is true for poly1305-generic
+which processes only one block at a time. However, it's not true for
+the AVX2 implementation, which processes 4 blocks at a time and
+therefore can produce intermediate limbs about 4x larger.
+
+Fix it by making the relevant calculations use 64-bit arithmetic rather
+than 32-bit. Note that most of the carries already used 64-bit
+arithmetic, but the d4 -> h0 carry was different for some reason.
+
+To be safe I also made the same change to the corresponding SSE2 code,
+though that only operates on 1 or 2 blocks at a time. I don't think
+it's really needed for poly1305_block_sse2(), but it doesn't hurt
+because it's already x86_64 code. It *might* be needed for
+poly1305_2block_sse2(), but overflows aren't easy to reproduce there.
+
+This bug was originally detected by my patches that improve testmgr to
+fuzz algorithms against their generic implementation. But also add a
+test vector which reproduces it directly (in the AVX2 case).
+
+Fixes: b1ccc8f4b631 ("crypto: poly1305 - Add a four block AVX2 variant for x86_64")
+Fixes: c70f4abef07a ("crypto: poly1305 - Add a SSE2 SIMD variant for x86_64")
+Cc: <stable@vger.kernel.org> # v4.3+
+Cc: Martin Willi <martin@strongswan.org>
+Cc: Jason A. Donenfeld <Jason@zx2c4.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Reviewed-by: Martin Willi <martin@strongswan.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/crypto/poly1305-avx2-x86_64.S | 14 +++++++---
+ arch/x86/crypto/poly1305-sse2-x86_64.S | 22 ++++++++++------
+ crypto/testmgr.h | 44 ++++++++++++++++++++++++++++++++-
+ 3 files changed, 67 insertions(+), 13 deletions(-)
+
+--- a/arch/x86/crypto/poly1305-avx2-x86_64.S
++++ b/arch/x86/crypto/poly1305-avx2-x86_64.S
+@@ -321,6 +321,12 @@ ENTRY(poly1305_4block_avx2)
+ vpaddq t2,t1,t1
+ vmovq t1x,d4
+
++ # Now do a partial reduction mod (2^130)-5, carrying h0 -> h1 -> h2 ->
++ # h3 -> h4 -> h0 -> h1 to get h0,h2,h3,h4 < 2^26 and h1 < 2^26 + a small
++ # amount. Careful: we must not assume the carry bits 'd0 >> 26',
++ # 'd1 >> 26', 'd2 >> 26', 'd3 >> 26', and '(d4 >> 26) * 5' fit in 32-bit
++ # integers. It's true in a single-block implementation, but not here.
++
+ # d1 += d0 >> 26
+ mov d0,%rax
+ shr $26,%rax
+@@ -359,16 +365,16 @@ ENTRY(poly1305_4block_avx2)
+ # h0 += (d4 >> 26) * 5
+ mov d4,%rax
+ shr $26,%rax
+- lea (%eax,%eax,4),%eax
+- add %eax,%ebx
++ lea (%rax,%rax,4),%rax
++ add %rax,%rbx
+ # h4 = d4 & 0x3ffffff
+ mov d4,%rax
+ and $0x3ffffff,%eax
+ mov %eax,h4
+
+ # h1 += h0 >> 26
+- mov %ebx,%eax
+- shr $26,%eax
++ mov %rbx,%rax
++ shr $26,%rax
+ add %eax,h1
+ # h0 = h0 & 0x3ffffff
+ andl $0x3ffffff,%ebx
+--- a/arch/x86/crypto/poly1305-sse2-x86_64.S
++++ b/arch/x86/crypto/poly1305-sse2-x86_64.S
+@@ -251,16 +251,16 @@ ENTRY(poly1305_block_sse2)
+ # h0 += (d4 >> 26) * 5
+ mov d4,%rax
+ shr $26,%rax
+- lea (%eax,%eax,4),%eax
+- add %eax,%ebx
++ lea (%rax,%rax,4),%rax
++ add %rax,%rbx
+ # h4 = d4 & 0x3ffffff
+ mov d4,%rax
+ and $0x3ffffff,%eax
+ mov %eax,h4
+
+ # h1 += h0 >> 26
+- mov %ebx,%eax
+- shr $26,%eax
++ mov %rbx,%rax
++ shr $26,%rax
+ add %eax,h1
+ # h0 = h0 & 0x3ffffff
+ andl $0x3ffffff,%ebx
+@@ -518,6 +518,12 @@ ENTRY(poly1305_2block_sse2)
+ paddq t2,t1
+ movq t1,d4
+
++ # Now do a partial reduction mod (2^130)-5, carrying h0 -> h1 -> h2 ->
++ # h3 -> h4 -> h0 -> h1 to get h0,h2,h3,h4 < 2^26 and h1 < 2^26 + a small
++ # amount. Careful: we must not assume the carry bits 'd0 >> 26',
++ # 'd1 >> 26', 'd2 >> 26', 'd3 >> 26', and '(d4 >> 26) * 5' fit in 32-bit
++ # integers. It's true in a single-block implementation, but not here.
++
+ # d1 += d0 >> 26
+ mov d0,%rax
+ shr $26,%rax
+@@ -556,16 +562,16 @@ ENTRY(poly1305_2block_sse2)
+ # h0 += (d4 >> 26) * 5
+ mov d4,%rax
+ shr $26,%rax
+- lea (%eax,%eax,4),%eax
+- add %eax,%ebx
++ lea (%rax,%rax,4),%rax
++ add %rax,%rbx
+ # h4 = d4 & 0x3ffffff
+ mov d4,%rax
+ and $0x3ffffff,%eax
+ mov %eax,h4
+
+ # h1 += h0 >> 26
+- mov %ebx,%eax
+- shr $26,%eax
++ mov %rbx,%rax
++ shr $26,%rax
+ add %eax,h1
+ # h0 = h0 & 0x3ffffff
+ andl $0x3ffffff,%ebx
+--- a/crypto/testmgr.h
++++ b/crypto/testmgr.h
+@@ -3494,7 +3494,49 @@ static struct hash_testvec poly1305_tv_t
+ .psize = 80,
+ .digest = "\x13\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00",
+- },
++ }, { /* Regression test for overflow in AVX2 implementation */
++ .plaintext = "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff",
++ .psize = 300,
++ .digest = "\xfb\x5e\x96\xd8\x61\xd5\xc7\xc8"
++ "\x78\xe5\x87\xcc\x2d\x5a\x22\xe1",
++ }
+ };
+
+ /*
--- /dev/null
+From fccfb9ce70ed4ea7a145f77b86de62e38178517f Mon Sep 17 00:00:00 2001
+From: Dragos Bogdan <dragos.bogdan@analog.com>
+Date: Tue, 19 Mar 2019 12:47:00 +0200
+Subject: iio: ad_sigma_delta: select channel when reading register
+
+From: Dragos Bogdan <dragos.bogdan@analog.com>
+
+commit fccfb9ce70ed4ea7a145f77b86de62e38178517f upstream.
+
+The desired channel has to be selected in order to correctly fill the
+buffer with the corresponding data.
+The `ad_sd_write_reg()` already does this, but for the
+`ad_sd_read_reg_raw()` this was omitted.
+
+Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices")
+Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
+Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.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/ad_sigma_delta.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/iio/adc/ad_sigma_delta.c
++++ b/drivers/iio/adc/ad_sigma_delta.c
+@@ -121,6 +121,7 @@ static int ad_sd_read_reg_raw(struct ad_
+ if (sigma_delta->info->has_registers) {
+ data[0] = reg << sigma_delta->info->addr_shift;
+ data[0] |= sigma_delta->info->read_mask;
++ data[0] |= sigma_delta->comm;
+ spi_message_add_tail(&t[0], &m);
+ }
+ spi_message_add_tail(&t[1], &m);
--- /dev/null
+From 09c6bdee51183a575bf7546890c8c137a75a2b44 Mon Sep 17 00:00:00 2001
+From: Georg Ottinger <g.ottinger@abatec.at>
+Date: Wed, 30 Jan 2019 14:42:02 +0100
+Subject: iio: adc: at91: disable adc channel interrupt in timeout case
+
+From: Georg Ottinger <g.ottinger@abatec.at>
+
+commit 09c6bdee51183a575bf7546890c8c137a75a2b44 upstream.
+
+Having a brief look at at91_adc_read_raw() it is obvious that in the case
+of a timeout the setting of AT91_ADC_CHDR and AT91_ADC_IDR registers is
+omitted. If 2 different channels are queried we can end up with a
+situation where two interrupts are enabled, but only one interrupt is
+cleared in the interrupt handler. Resulting in a interrupt loop and a
+system hang.
+
+Signed-off-by: Georg Ottinger <g.ottinger@abatec.at>
+Acked-by: Ludovic Desroches <ludovic.desroches@microchip.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/at91_adc.c | 28 +++++++++++++++++-----------
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+--- a/drivers/iio/adc/at91_adc.c
++++ b/drivers/iio/adc/at91_adc.c
+@@ -702,23 +702,29 @@ static int at91_adc_read_raw(struct iio_
+ ret = wait_event_interruptible_timeout(st->wq_data_avail,
+ st->done,
+ msecs_to_jiffies(1000));
+- if (ret == 0)
+- ret = -ETIMEDOUT;
+- if (ret < 0) {
+- mutex_unlock(&st->lock);
+- return ret;
+- }
+-
+- *val = st->last_value;
+
++ /* Disable interrupts, regardless if adc conversion was
++ * successful or not
++ */
+ at91_adc_writel(st, AT91_ADC_CHDR,
+ AT91_ADC_CH(chan->channel));
+ at91_adc_writel(st, AT91_ADC_IDR, BIT(chan->channel));
+
+- st->last_value = 0;
+- st->done = false;
++ if (ret > 0) {
++ /* a valid conversion took place */
++ *val = st->last_value;
++ st->last_value = 0;
++ st->done = false;
++ ret = IIO_VAL_INT;
++ } else if (ret == 0) {
++ /* conversion timeout */
++ dev_err(&idev->dev, "ADC Channel %d timeout.\n",
++ chan->channel);
++ ret = -ETIMEDOUT;
++ }
++
+ mutex_unlock(&st->lock);
+- return IIO_VAL_INT;
++ return ret;
+
+ case IIO_CHAN_INFO_SCALE:
+ *val = st->vref_mv;
--- /dev/null
+From 40a7198a4a01037003c7ca714f0d048a61e729ac Mon Sep 17 00:00:00 2001
+From: Mike Looijmans <mike.looijmans@topic.nl>
+Date: Wed, 13 Feb 2019 08:41:47 +0100
+Subject: iio/gyro/bmg160: Use millidegrees for temperature scale
+
+From: Mike Looijmans <mike.looijmans@topic.nl>
+
+commit 40a7198a4a01037003c7ca714f0d048a61e729ac upstream.
+
+Standard unit for temperature is millidegrees Celcius, whereas this driver
+was reporting in degrees. Fix the scale factor in the driver.
+
+Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
+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/gyro/bmg160_core.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/gyro/bmg160_core.c
++++ b/drivers/iio/gyro/bmg160_core.c
+@@ -519,11 +519,10 @@ static int bmg160_read_raw(struct iio_de
+ } else
+ return -EINVAL;
+ case IIO_CHAN_INFO_SCALE:
+- *val = 0;
+ switch (chan->type) {
+ case IIO_TEMP:
+- *val2 = 500000;
+- return IIO_VAL_INT_PLUS_MICRO;
++ *val = 500;
++ return IIO_VAL_INT;
+ case IIO_ANGL_VEL:
+ {
+ int i;
+@@ -531,6 +530,7 @@ static int bmg160_read_raw(struct iio_de
+ for (i = 0; i < ARRAY_SIZE(bmg160_scale_table); ++i) {
+ if (bmg160_scale_table[i].dps_range ==
+ data->dps_range) {
++ *val = 0;
+ *val2 = bmg160_scale_table[i].scale;
+ return IIO_VAL_INT_PLUS_MICRO;
+ }
--- /dev/null
+From fe2d3df639a7940a125a33d6460529b9689c5406 Mon Sep 17 00:00:00 2001
+From: "he, bo" <bo.he@intel.com>
+Date: Wed, 6 Mar 2019 10:32:20 +0800
+Subject: io: accel: kxcjk1013: restore the range after resume.
+
+From: he, bo <bo.he@intel.com>
+
+commit fe2d3df639a7940a125a33d6460529b9689c5406 upstream.
+
+On some laptops, kxcjk1013 is powered off when system enters S3. We need
+restore the range regiter during resume. Otherwise, the sensor doesn't
+work properly after S3.
+
+Signed-off-by: he, bo <bo.he@intel.com>
+Signed-off-by: Chen, Hu <hu1.chen@intel.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.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/accel/kxcjk-1013.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/iio/accel/kxcjk-1013.c
++++ b/drivers/iio/accel/kxcjk-1013.c
+@@ -1343,6 +1343,8 @@ static int kxcjk1013_resume(struct devic
+
+ mutex_lock(&data->mutex);
+ ret = kxcjk1013_set_mode(data, OPERATION);
++ if (ret == 0)
++ ret = kxcjk1013_set_range(data, data->range);
+ mutex_unlock(&data->mutex);
+
+ return ret;
--- /dev/null
+From 5f843ed415581cfad4ef8fefe31c138a8346ca8a Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Mon, 15 Apr 2019 15:01:25 +0900
+Subject: kprobes: Fix error check when reusing optimized probes
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+commit 5f843ed415581cfad4ef8fefe31c138a8346ca8a upstream.
+
+The following commit introduced a bug in one of our error paths:
+
+ 819319fc9346 ("kprobes: Return error if we fail to reuse kprobe instead of BUG_ON()")
+
+it missed to handle the return value of kprobe_optready() as
+error-value. In reality, the kprobe_optready() returns a bool
+result, so "true" case must be passed instead of 0.
+
+This causes some errors on kprobe boot-time selftests on ARM:
+
+ [ ] Beginning kprobe tests...
+ [ ] Probe ARM code
+ [ ] kprobe
+ [ ] kretprobe
+ [ ] ARM instruction simulation
+ [ ] Check decoding tables
+ [ ] Run test cases
+ [ ] FAIL: test_case_handler not run
+ [ ] FAIL: Test andge r10, r11, r14, asr r7
+ [ ] FAIL: Scenario 11
+ ...
+ [ ] FAIL: Scenario 7
+ [ ] Total instruction simulation tests=1631, pass=1433 fail=198
+ [ ] kprobe tests failed
+
+This can happen if an optimized probe is unregistered and next
+kprobe is registered on same address until the previous probe
+is not reclaimed.
+
+If this happens, a hidden aggregated probe may be kept in memory,
+and no new kprobe can probe same address. Also, in that case
+register_kprobe() will return "1" instead of minus error value,
+which can mislead caller logic.
+
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
+Cc: David S . Miller <davem@davemloft.net>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Naveen N . Rao <naveen.n.rao@linux.vnet.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org # v5.0+
+Fixes: 819319fc9346 ("kprobes: Return error if we fail to reuse kprobe instead of BUG_ON()")
+Link: http://lkml.kernel.org/r/155530808559.32517.539898325433642204.stgit@devnote2
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/kprobes.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/kernel/kprobes.c
++++ b/kernel/kprobes.c
+@@ -668,7 +668,6 @@ static void unoptimize_kprobe(struct kpr
+ static int reuse_unused_kprobe(struct kprobe *ap)
+ {
+ struct optimized_kprobe *op;
+- int ret;
+
+ BUG_ON(!kprobe_unused(ap));
+ /*
+@@ -682,9 +681,8 @@ static int reuse_unused_kprobe(struct kp
+ /* Enable the probe again */
+ ap->flags &= ~KPROBE_FLAG_DISABLED;
+ /* Optimize it again (remove from op->list) */
+- ret = kprobe_optready(ap);
+- if (ret)
+- return ret;
++ if (!kprobe_optready(ap))
++ return -EINVAL;
+
+ optimize_kprobe(ap);
+ return 0;
--- /dev/null
+From fabe38ab6b2bd9418350284c63825f13b8a6abba Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Sun, 24 Feb 2019 01:50:20 +0900
+Subject: kprobes: Mark ftrace mcount handler functions nokprobe
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+commit fabe38ab6b2bd9418350284c63825f13b8a6abba upstream.
+
+Mark ftrace mcount handler functions nokprobe since
+probing on these functions with kretprobe pushes
+return address incorrectly on kretprobe shadow stack.
+
+Reported-by: Francis Deslauriers <francis.deslauriers@efficios.com>
+Tested-by: Andrea Righi <righi.andrea@gmail.com>
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Acked-by: Steven Rostedt <rostedt@goodmis.org>
+Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/155094062044.6137.6419622920568680640.stgit@devbox
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/ftrace.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -32,6 +32,7 @@
+ #include <linux/list.h>
+ #include <linux/hash.h>
+ #include <linux/rcupdate.h>
++#include <linux/kprobes.h>
+
+ #include <trace/events/sched.h>
+
+@@ -5165,7 +5166,7 @@ static struct ftrace_ops control_ops = {
+ INIT_OPS_HASH(control_ops)
+ };
+
+-static inline void
++static nokprobe_inline void
+ __ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *ignored, struct pt_regs *regs)
+ {
+@@ -5214,11 +5215,13 @@ static void ftrace_ops_list_func(unsigne
+ {
+ __ftrace_ops_list_func(ip, parent_ip, NULL, regs);
+ }
++NOKPROBE_SYMBOL(ftrace_ops_list_func);
+ #else
+ static void ftrace_ops_no_ops(unsigned long ip, unsigned long parent_ip)
+ {
+ __ftrace_ops_list_func(ip, parent_ip, NULL, NULL);
+ }
++NOKPROBE_SYMBOL(ftrace_ops_no_ops);
+ #endif
+
+ /*
+@@ -5239,6 +5242,7 @@ static void ftrace_ops_recurs_func(unsig
+
+ trace_clear_recursion(bit);
+ }
++NOKPROBE_SYMBOL(ftrace_ops_assist_func);
+
+ /**
+ * ftrace_ops_get_func - get the function a trampoline should call
--- /dev/null
+From 8f4dc2e77cdfaf7e644ef29693fa229db29ee1de Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Tue, 2 Apr 2019 08:10:47 -0700
+Subject: KVM: x86: Don't clear EFER during SMM transitions for 32-bit vCPU
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+commit 8f4dc2e77cdfaf7e644ef29693fa229db29ee1de upstream.
+
+Neither AMD nor Intel CPUs have an EFER field in the legacy SMRAM save
+state area, i.e. don't save/restore EFER across SMM transitions. KVM
+somewhat models this, e.g. doesn't clear EFER on entry to SMM if the
+guest doesn't support long mode. But during RSM, KVM unconditionally
+clears EFER so that it can get back to pure 32-bit mode in order to
+start loading CRs with their actual non-SMM values.
+
+Clear EFER only when it will be written when loading the non-SMM state
+so as to preserve bits that can theoretically be set on 32-bit vCPUs,
+e.g. KVM always emulates EFER_SCE.
+
+And because CR4.PAE is cleared only to play nice with EFER, wrap that
+code in the long mode check as well. Note, this may result in a
+compiler warning about cr4 being consumed uninitialized. Re-read CR4
+even though it's technically unnecessary, as doing so allows for more
+readable code and RSM emulation is not a performance critical path.
+
+Fixes: 660a5d517aaab ("KVM: x86: save/load state on SMM switch")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/emulate.c | 23 ++++++++++++-----------
+ 1 file changed, 12 insertions(+), 11 deletions(-)
+
+--- a/arch/x86/kvm/emulate.c
++++ b/arch/x86/kvm/emulate.c
+@@ -2567,15 +2567,13 @@ static int em_rsm(struct x86_emulate_ctx
+ * CR0/CR3/CR4/EFER. It's all a bit more complicated if the vCPU
+ * supports long mode.
+ */
+- cr4 = ctxt->ops->get_cr(ctxt, 4);
+ if (emulator_has_longmode(ctxt)) {
+ struct desc_struct cs_desc;
+
+ /* Zero CR4.PCIDE before CR0.PG. */
+- if (cr4 & X86_CR4_PCIDE) {
++ cr4 = ctxt->ops->get_cr(ctxt, 4);
++ if (cr4 & X86_CR4_PCIDE)
+ ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PCIDE);
+- cr4 &= ~X86_CR4_PCIDE;
+- }
+
+ /* A 32-bit code segment is required to clear EFER.LMA. */
+ memset(&cs_desc, 0, sizeof(cs_desc));
+@@ -2589,13 +2587,16 @@ static int em_rsm(struct x86_emulate_ctx
+ if (cr0 & X86_CR0_PE)
+ ctxt->ops->set_cr(ctxt, 0, cr0 & ~(X86_CR0_PG | X86_CR0_PE));
+
+- /* Now clear CR4.PAE (which must be done before clearing EFER.LME). */
+- if (cr4 & X86_CR4_PAE)
+- ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PAE);
+-
+- /* And finally go back to 32-bit mode. */
+- efer = 0;
+- ctxt->ops->set_msr(ctxt, MSR_EFER, efer);
++ if (emulator_has_longmode(ctxt)) {
++ /* Clear CR4.PAE before clearing EFER.LME. */
++ cr4 = ctxt->ops->get_cr(ctxt, 4);
++ if (cr4 & X86_CR4_PAE)
++ ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PAE);
++
++ /* And finally go back to 32-bit mode. */
++ efer = 0;
++ ctxt->ops->set_msr(ctxt, MSR_EFER, efer);
++ }
+
+ smbase = ctxt->ops->get_smbase(ctxt);
+ if (emulator_has_longmode(ctxt))
--- /dev/null
+From 4856bfd230985e43e84c26473c91028ff0a533bd Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@nbd.name>
+Date: Fri, 1 Mar 2019 14:48:37 +0100
+Subject: mac80211: do not call driver wake_tx_queue op during reconfig
+
+From: Felix Fietkau <nbd@nbd.name>
+
+commit 4856bfd230985e43e84c26473c91028ff0a533bd upstream.
+
+There are several scenarios in which mac80211 can call drv_wake_tx_queue
+after ieee80211_restart_hw has been called and has not yet completed.
+Driver private structs are considered uninitialized until mac80211 has
+uploaded the vifs, stations and keys again, so using private tx queue
+data during that time is not safe.
+
+The driver can also not rely on drv_reconfig_complete to figure out when
+it is safe to accept drv_wake_tx_queue calls again, because it is only
+called after all tx queues are woken again.
+
+To fix this, bail out early in drv_wake_tx_queue if local->in_reconfig
+is set.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/driver-ops.h | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/mac80211/driver-ops.h
++++ b/net/mac80211/driver-ops.h
+@@ -1157,6 +1157,9 @@ static inline void drv_wake_tx_queue(str
+ {
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(txq->txq.vif);
+
++ if (local->in_reconfig)
++ return;
++
+ if (!check_sdata_in_driver(sdata))
+ return;
+
modpost-file2alias-go-back-to-simple-devtable-lookup.patch
modpost-file2alias-check-prototype-of-handler.patch
tpm-tpm_i2c_atmel-return-e2big-when-the-transfer-is-.patch
+kvm-x86-don-t-clear-efer-during-smm-transitions-for-32-bit-vcpu.patch
+iio-gyro-bmg160-use-millidegrees-for-temperature-scale.patch
+iio-ad_sigma_delta-select-channel-when-reading-register.patch
+iio-adc-at91-disable-adc-channel-interrupt-in-timeout-case.patch
+io-accel-kxcjk1013-restore-the-range-after-resume.patch
+staging-comedi-vmk80xx-fix-use-of-uninitialized-semaphore.patch
+staging-comedi-vmk80xx-fix-possible-double-free-of-usb_rx_buf.patch
+staging-comedi-ni_usb6501-fix-use-of-uninitialized-mutex.patch
+staging-comedi-ni_usb6501-fix-possible-double-free-of-usb_rx_buf.patch
+alsa-core-fix-card-races-between-register-and-disconnect.patch
+crypto-x86-poly1305-fix-overflow-during-partial-reduction.patch
+arm64-futex-restore-oldval-initialization-to-work-around-buggy-compilers.patch
+x86-kprobes-verify-stack-frame-on-kretprobe.patch
+kprobes-mark-ftrace-mcount-handler-functions-nokprobe.patch
+kprobes-fix-error-check-when-reusing-optimized-probes.patch
+mac80211-do-not-call-driver-wake_tx_queue-op-during-reconfig.patch
--- /dev/null
+From af4b54a2e5ba18259ff9aac445bf546dd60d037e Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 15 Apr 2019 12:43:02 +0100
+Subject: staging: comedi: ni_usb6501: Fix possible double-free of ->usb_rx_buf
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit af4b54a2e5ba18259ff9aac445bf546dd60d037e upstream.
+
+`ni6501_alloc_usb_buffers()` is called from `ni6501_auto_attach()` to
+allocate RX and TX buffers for USB transfers. It allocates
+`devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`. If the
+allocation of `devpriv->usb_tx_buf` fails, it frees
+`devpriv->usb_rx_buf`, leaving the pointer set dangling, and returns an
+error. Later, `ni6501_detach()` will be called from the core comedi
+module code to clean up. `ni6501_detach()` also frees both
+`devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
+`devpriv->usb_rx_buf` may have already beed freed, leading to a
+double-free error. Fix it bu removing the call to
+`kfree(devpriv->usb_rx_buf)` from `ni6501_alloc_usb_buffers()`, relying
+on `ni6501_detach()` to free the memory.
+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/ni_usb6501.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/ni_usb6501.c
++++ b/drivers/staging/comedi/drivers/ni_usb6501.c
+@@ -472,10 +472,8 @@ static int ni6501_alloc_usb_buffers(stru
+
+ size = le16_to_cpu(devpriv->ep_tx->wMaxPacketSize);
+ devpriv->usb_tx_buf = kzalloc(size, GFP_KERNEL);
+- if (!devpriv->usb_tx_buf) {
+- kfree(devpriv->usb_rx_buf);
++ if (!devpriv->usb_tx_buf)
+ return -ENOMEM;
+- }
+
+ return 0;
+ }
--- /dev/null
+From 660cf4ce9d0f3497cc7456eaa6d74c8b71d6282c Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 15 Apr 2019 12:43:01 +0100
+Subject: staging: comedi: ni_usb6501: Fix use of uninitialized mutex
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 660cf4ce9d0f3497cc7456eaa6d74c8b71d6282c upstream.
+
+If `ni6501_auto_attach()` returns an error, the core comedi module code
+will call `ni6501_detach()` to clean up. If `ni6501_auto_attach()`
+successfully allocated the comedi device private data, `ni6501_detach()`
+assumes that a `struct mutex mut` contained in the private data has been
+initialized and uses it. Unfortunately, there are a couple of places
+where `ni6501_auto_attach()` can return an error after allocating the
+device private data but before initializing the mutex, so this
+assumption is invalid. Fix it by initializing the mutex just after
+allocating the private data in `ni6501_auto_attach()` before any other
+errors can be retturned. Also move the call to `usb_set_intfdata()`
+just to keep the code a bit neater (either position for the call is
+fine).
+
+I believe this was the cause of the following syzbot crash report
+<https://syzkaller.appspot.com/bug?extid=cf4f2b6c24aff0a3edf6>:
+
+usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
+usb 1-1: config 0 descriptor??
+usb 1-1: string descriptor 0 read error: -71
+comedi comedi0: Wrong number of endpoints
+ni6501 1-1:0.233: driver 'ni6501' failed to auto-configure device.
+INFO: trying to register non-static key.
+the code is fine but needs lockdep annotation.
+turning off the locking correctness validator.
+CPU: 0 PID: 585 Comm: kworker/0:3 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Workqueue: usb_hub_wq hub_event
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xe8/0x16e lib/dump_stack.c:113
+ assign_lock_key kernel/locking/lockdep.c:786 [inline]
+ register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
+ __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
+ lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
+ __mutex_lock_common kernel/locking/mutex.c:925 [inline]
+ __mutex_lock+0xfe/0x12b0 kernel/locking/mutex.c:1072
+ ni6501_detach+0x5b/0x110 drivers/staging/comedi/drivers/ni_usb6501.c:567
+ comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
+ comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
+ comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
+ comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
+ comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
+ comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
+ comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
+ usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
+ really_probe+0x2da/0xb10 drivers/base/dd.c:509
+ driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
+ __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
+ bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
+ __device_attach+0x223/0x3a0 drivers/base/dd.c:844
+ bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
+ device_add+0xad2/0x16e0 drivers/base/core.c:2106
+ usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
+ generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
+ usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
+ really_probe+0x2da/0xb10 drivers/base/dd.c:509
+ driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
+ __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
+ bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
+ __device_attach+0x223/0x3a0 drivers/base/dd.c:844
+ bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
+ device_add+0xad2/0x16e0 drivers/base/core.c:2106
+ usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
+ hub_port_connect drivers/usb/core/hub.c:5089 [inline]
+ hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
+ port_event drivers/usb/core/hub.c:5350 [inline]
+ hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
+ process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
+ worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
+ kthread+0x313/0x420 kernel/kthread.c:253
+ ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
+
+Reported-by: syzbot+cf4f2b6c24aff0a3edf6@syzkaller.appspotmail.com
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/ni_usb6501.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/ni_usb6501.c
++++ b/drivers/staging/comedi/drivers/ni_usb6501.c
+@@ -527,6 +527,9 @@ static int ni6501_auto_attach(struct com
+ if (!devpriv)
+ return -ENOMEM;
+
++ mutex_init(&devpriv->mut);
++ usb_set_intfdata(intf, devpriv);
++
+ ret = ni6501_find_endpoints(dev);
+ if (ret)
+ return ret;
+@@ -535,9 +538,6 @@ static int ni6501_auto_attach(struct com
+ if (ret)
+ return ret;
+
+- mutex_init(&devpriv->mut);
+- usb_set_intfdata(intf, devpriv);
+-
+ ret = comedi_alloc_subdevices(dev, 2);
+ if (ret)
+ return ret;
--- /dev/null
+From 663d294b4768bfd89e529e069bffa544a830b5bf Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 15 Apr 2019 12:52:30 +0100
+Subject: staging: comedi: vmk80xx: Fix possible double-free of ->usb_rx_buf
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 663d294b4768bfd89e529e069bffa544a830b5bf upstream.
+
+`vmk80xx_alloc_usb_buffers()` is called from `vmk80xx_auto_attach()` to
+allocate RX and TX buffers for USB transfers. It allocates
+`devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`. If the
+allocation of `devpriv->usb_tx_buf` fails, it frees
+`devpriv->usb_rx_buf`, leaving the pointer set dangling, and returns an
+error. Later, `vmk80xx_detach()` will be called from the core comedi
+module code to clean up. `vmk80xx_detach()` also frees both
+`devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
+`devpriv->usb_rx_buf` may have already been freed, leading to a
+double-free error. Fix it by removing the call to
+`kfree(devpriv->usb_rx_buf)` from `vmk80xx_alloc_usb_buffers()`, relying
+on `vmk80xx_detach()` to free the memory.
+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/vmk80xx.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/vmk80xx.c
++++ b/drivers/staging/comedi/drivers/vmk80xx.c
+@@ -691,10 +691,8 @@ static int vmk80xx_alloc_usb_buffers(str
+
+ size = le16_to_cpu(devpriv->ep_tx->wMaxPacketSize);
+ devpriv->usb_tx_buf = kzalloc(size, GFP_KERNEL);
+- if (!devpriv->usb_tx_buf) {
+- kfree(devpriv->usb_rx_buf);
++ if (!devpriv->usb_tx_buf)
+ return -ENOMEM;
+- }
+
+ return 0;
+ }
--- /dev/null
+From 08b7c2f9208f0e2a32159e4e7a4831b7adb10a3e Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 15 Apr 2019 12:10:14 +0100
+Subject: staging: comedi: vmk80xx: Fix use of uninitialized semaphore
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 08b7c2f9208f0e2a32159e4e7a4831b7adb10a3e upstream.
+
+If `vmk80xx_auto_attach()` returns an error, the core comedi module code
+will call `vmk80xx_detach()` to clean up. If `vmk80xx_auto_attach()`
+successfully allocated the comedi device private data,
+`vmk80xx_detach()` assumes that a `struct semaphore limit_sem` contained
+in the private data has been initialized and uses it. Unfortunately,
+there are a couple of places where `vmk80xx_auto_attach()` can return an
+error after allocating the device private data but before initializing
+the semaphore, so this assumption is invalid. Fix it by initializing
+the semaphore just after allocating the private data in
+`vmk80xx_auto_attach()` before any other errors can be returned.
+
+I believe this was the cause of the following syzbot crash report
+<https://syzkaller.appspot.com/bug?extid=54c2f58f15fe6876b6ad>:
+
+usb 1-1: config 0 has no interface number 0
+usb 1-1: New USB device found, idVendor=10cf, idProduct=8068, bcdDevice=e6.8d
+usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
+usb 1-1: config 0 descriptor??
+vmk80xx 1-1:0.117: driver 'vmk80xx' failed to auto-configure device.
+INFO: trying to register non-static key.
+the code is fine but needs lockdep annotation.
+turning off the locking correctness validator.
+CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Workqueue: usb_hub_wq hub_event
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xe8/0x16e lib/dump_stack.c:113
+ assign_lock_key kernel/locking/lockdep.c:786 [inline]
+ register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
+ __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
+ lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
+ __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
+ _raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
+ down+0x12/0x80 kernel/locking/semaphore.c:58
+ vmk80xx_detach+0x59/0x100 drivers/staging/comedi/drivers/vmk80xx.c:829
+ comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
+ comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
+ comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
+ comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
+ comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
+ comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
+ comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
+ usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
+ really_probe+0x2da/0xb10 drivers/base/dd.c:509
+ driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
+ __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
+ bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
+ __device_attach+0x223/0x3a0 drivers/base/dd.c:844
+ bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
+ device_add+0xad2/0x16e0 drivers/base/core.c:2106
+ usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
+ generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
+ usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
+ really_probe+0x2da/0xb10 drivers/base/dd.c:509
+ driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
+ __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
+ bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
+ __device_attach+0x223/0x3a0 drivers/base/dd.c:844
+ bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
+ device_add+0xad2/0x16e0 drivers/base/core.c:2106
+ usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
+ hub_port_connect drivers/usb/core/hub.c:5089 [inline]
+ hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
+ port_event drivers/usb/core/hub.c:5350 [inline]
+ hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
+ process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
+ worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
+ kthread+0x313/0x420 kernel/kthread.c:253
+ ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
+
+Reported-by: syzbot+54c2f58f15fe6876b6ad@syzkaller.appspotmail.com
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/vmk80xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/vmk80xx.c
++++ b/drivers/staging/comedi/drivers/vmk80xx.c
+@@ -809,6 +809,8 @@ static int vmk80xx_auto_attach(struct co
+
+ devpriv->model = board->model;
+
++ sema_init(&devpriv->limit_sem, 8);
++
+ ret = vmk80xx_find_usb_endpoints(dev);
+ if (ret)
+ return ret;
+@@ -817,8 +819,6 @@ static int vmk80xx_auto_attach(struct co
+ if (ret)
+ return ret;
+
+- sema_init(&devpriv->limit_sem, 8);
+-
+ usb_set_intfdata(intf, devpriv);
+
+ if (devpriv->model == VMK8055_MODEL)
--- /dev/null
+From 3ff9c075cc767b3060bdac12da72fc94dd7da1b8 Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Sun, 24 Feb 2019 01:49:52 +0900
+Subject: x86/kprobes: Verify stack frame on kretprobe
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+commit 3ff9c075cc767b3060bdac12da72fc94dd7da1b8 upstream.
+
+Verify the stack frame pointer on kretprobe trampoline handler,
+If the stack frame pointer does not match, it skips the wrong
+entry and tries to find correct one.
+
+This can happen if user puts the kretprobe on the function
+which can be used in the path of ftrace user-function call.
+Such functions should not be probed, so this adds a warning
+message that reports which function should be blacklisted.
+
+Tested-by: Andrea Righi <righi.andrea@gmail.com>
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Acked-by: Steven Rostedt <rostedt@goodmis.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/155094059185.6137.15527904013362842072.stgit@devbox
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/kprobes/core.c | 26 ++++++++++++++++++++++++++
+ include/linux/kprobes.h | 1 +
+ 2 files changed, 27 insertions(+)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -541,6 +541,7 @@ void arch_prepare_kretprobe(struct kretp
+ unsigned long *sara = stack_addr(regs);
+
+ ri->ret_addr = (kprobe_opcode_t *) *sara;
++ ri->fp = sara;
+
+ /* Replace the return addr with trampoline addr */
+ *sara = (unsigned long) &kretprobe_trampoline;
+@@ -742,15 +743,21 @@ __visible __used void *trampoline_handle
+ unsigned long flags, orig_ret_address = 0;
+ unsigned long trampoline_address = (unsigned long)&kretprobe_trampoline;
+ kprobe_opcode_t *correct_ret_addr = NULL;
++ void *frame_pointer;
++ bool skipped = false;
+
+ INIT_HLIST_HEAD(&empty_rp);
+ kretprobe_hash_lock(current, &head, &flags);
+ /* fixup registers */
+ #ifdef CONFIG_X86_64
+ regs->cs = __KERNEL_CS;
++ /* On x86-64, we use pt_regs->sp for return address holder. */
++ frame_pointer = ®s->sp;
+ #else
+ regs->cs = __KERNEL_CS | get_kernel_rpl();
+ regs->gs = 0;
++ /* On x86-32, we use pt_regs->flags for return address holder. */
++ frame_pointer = ®s->flags;
+ #endif
+ regs->ip = trampoline_address;
+ regs->orig_ax = ~0UL;
+@@ -772,8 +779,25 @@ __visible __used void *trampoline_handle
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
++ /*
++ * Return probes must be pushed on this hash list correct
++ * order (same as return order) so that it can be poped
++ * correctly. However, if we find it is pushed it incorrect
++ * order, this means we find a function which should not be
++ * probed, because the wrong order entry is pushed on the
++ * path of processing other kretprobe itself.
++ */
++ if (ri->fp != frame_pointer) {
++ if (!skipped)
++ pr_warn("kretprobe is stacked incorrectly. Trying to fixup.\n");
++ skipped = true;
++ continue;
++ }
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
++ if (skipped)
++ pr_warn("%ps must be blacklisted because of incorrect kretprobe order\n",
++ ri->rp->kp.addr);
+
+ if (orig_ret_address != trampoline_address)
+ /*
+@@ -791,6 +815,8 @@ __visible __used void *trampoline_handle
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
++ if (ri->fp != frame_pointer)
++ continue;
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
+ if (ri->rp && ri->rp->handler) {
+--- a/include/linux/kprobes.h
++++ b/include/linux/kprobes.h
+@@ -197,6 +197,7 @@ struct kretprobe_instance {
+ struct kretprobe *rp;
+ kprobe_opcode_t *ret_addr;
+ struct task_struct *task;
++ void *fp;
+ char data[0];
+ };
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
