]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 4.4
authorSasha Levin <sashal@kernel.org>
Thu, 21 May 2020 14:04:53 +0000 (10:04 -0400)
committerSasha Levin <sashal@kernel.org>
Thu, 21 May 2020 14:04:53 +0000 (10:04 -0400)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.4/arm-futex-address-build-warning.patch [new file with mode: 0644]
queue-4.4/ceph-fix-double-unlock-in-handle_cap_export.patch [new file with mode: 0644]
queue-4.4/evm-check-also-if-tfm-is-an-error-pointer-in-init_de.patch [new file with mode: 0644]
queue-4.4/fix-multiplication-overflow-in-copy_fdtable.patch [new file with mode: 0644]
queue-4.4/hid-multitouch-add-egalaxtouch-p80h84-support.patch [new file with mode: 0644]
queue-4.4/platform-x86-asus-nb-wmi-do-not-load-on-asus-t100ta-.patch [new file with mode: 0644]
queue-4.4/series
queue-4.4/usb-core-fix-misleading-driver-bug-report.patch [new file with mode: 0644]

diff --git a/queue-4.4/arm-futex-address-build-warning.patch b/queue-4.4/arm-futex-address-build-warning.patch
new file mode 100644 (file)
index 0000000..3d003b9
--- /dev/null
@@ -0,0 +1,70 @@
+From a9ede92b2895739b11fa3dfb75bc7abb1e10a4a1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Apr 2020 11:07:22 +0200
+Subject: ARM: futex: Address build warning
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+[ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ]
+
+Stephen reported the following build warning on a ARM multi_v7_defconfig
+build with GCC 9.2.1:
+
+kernel/futex.c: In function 'do_futex':
+kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
+ 1676 |   return oldval == cmparg;
+      |          ~~~~~~~^~~~~~~~~
+kernel/futex.c:1652:6: note: 'oldval' was declared here
+ 1652 |  int oldval, ret;
+      |      ^~~~~~
+
+introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser()
+calling conventions change").
+
+While that change should not make any difference it confuses GCC which
+fails to work out that oldval is not referenced when the return value is
+not zero.
+
+GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the
+early return, the issue is with the assembly macros. GCC fails to detect
+that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT
+which makes oldval uninteresting. The store to the callsite supplied oldval
+pointer is conditional on ret == 0.
+
+The straight forward way to solve this is to make the store unconditional.
+
+Aside of addressing the build warning this makes sense anyway because it
+removes the conditional from the fastpath. In the error case the stored
+value is uninteresting and the extra store does not matter at all.
+
+Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/include/asm/futex.h | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
+index cc414382dab4..561b2ba6bc28 100644
+--- a/arch/arm/include/asm/futex.h
++++ b/arch/arm/include/asm/futex.h
+@@ -162,8 +162,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
+       preempt_enable();
+ #endif
+-      if (!ret)
+-              *oval = oldval;
++      /*
++       * Store unconditionally. If ret != 0 the extra store is the least
++       * of the worries but GCC cannot figure out that __futex_atomic_op()
++       * is either setting ret to -EFAULT or storing the old value in
++       * oldval which results in a uninitialized warning at the call site.
++       */
++      *oval = oldval;
+       return ret;
+ }
+-- 
+2.25.1
+
diff --git a/queue-4.4/ceph-fix-double-unlock-in-handle_cap_export.patch b/queue-4.4/ceph-fix-double-unlock-in-handle_cap_export.patch
new file mode 100644 (file)
index 0000000..6979474
--- /dev/null
@@ -0,0 +1,37 @@
+From 03149bb6605df96f8d64d57e8e8bc343c657d282 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 30 Apr 2020 14:12:49 +0800
+Subject: ceph: fix double unlock in handle_cap_export()
+
+From: Wu Bo <wubo40@huawei.com>
+
+[ Upstream commit 4d8e28ff3106b093d98bfd2eceb9b430c70a8758 ]
+
+If the ceph_mdsc_open_export_target_session() return fails, it will
+do a "goto retry", but the session mutex has already been unlocked.
+Re-lock the mutex in that case to ensure that we don't unlock it
+twice.
+
+Signed-off-by: Wu Bo <wubo40@huawei.com>
+Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/ceph/caps.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
+index efdf81ea3b5f..3d0497421e62 100644
+--- a/fs/ceph/caps.c
++++ b/fs/ceph/caps.c
+@@ -3293,6 +3293,7 @@ retry:
+               WARN_ON(1);
+               tsession = NULL;
+               target = -1;
++              mutex_lock(&session->s_mutex);
+       }
+       goto retry;
+-- 
+2.25.1
+
diff --git a/queue-4.4/evm-check-also-if-tfm-is-an-error-pointer-in-init_de.patch b/queue-4.4/evm-check-also-if-tfm-is-an-error-pointer-in-init_de.patch
new file mode 100644 (file)
index 0000000..c387d24
--- /dev/null
@@ -0,0 +1,49 @@
+From cb5bd2b20b8f18f1acfc6125d697e023047c3226 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 27 Apr 2020 12:28:56 +0200
+Subject: evm: Check also if *tfm is an error pointer in init_desc()
+
+From: Roberto Sassu <roberto.sassu@huawei.com>
+
+[ Upstream commit 53de3b080d5eae31d0de219617155dcc34e7d698 ]
+
+This patch avoids a kernel panic due to accessing an error pointer set by
+crypto_alloc_shash(). It occurs especially when there are many files that
+require an unsupported algorithm, as it would increase the likelihood of
+the following race condition:
+
+Task A: *tfm = crypto_alloc_shash() <= error pointer
+Task B: if (*tfm == NULL) <= *tfm is not NULL, use it
+Task B: rc = crypto_shash_init(desc) <= panic
+Task A: *tfm = NULL
+
+This patch uses the IS_ERR_OR_NULL macro to determine whether or not a new
+crypto context must be created.
+
+Cc: stable@vger.kernel.org
+Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
+Co-developed-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
+Signed-off-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
+Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ security/integrity/evm/evm_crypto.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
+index 461f8d891579..44352b0b7510 100644
+--- a/security/integrity/evm/evm_crypto.c
++++ b/security/integrity/evm/evm_crypto.c
+@@ -47,7 +47,7 @@ static struct shash_desc *init_desc(char type)
+               algo = evm_hash;
+       }
+-      if (*tfm == NULL) {
++      if (IS_ERR_OR_NULL(*tfm)) {
+               mutex_lock(&mutex);
+               if (*tfm)
+                       goto out;
+-- 
+2.25.1
+
diff --git a/queue-4.4/fix-multiplication-overflow-in-copy_fdtable.patch b/queue-4.4/fix-multiplication-overflow-in-copy_fdtable.patch
new file mode 100644 (file)
index 0000000..bc55735
--- /dev/null
@@ -0,0 +1,40 @@
+From bf2e6978dabdd761082d57d0aa4686547169745d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 19 May 2020 17:48:52 -0400
+Subject: fix multiplication overflow in copy_fdtable()
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit 4e89b7210403fa4a8acafe7c602b6212b7af6c3b ]
+
+cpy and set really should be size_t; we won't get an overflow on that,
+since sysctl_nr_open can't be set above ~(size_t)0 / sizeof(void *),
+so nr that would've managed to overflow size_t on that multiplication
+won't get anywhere near copy_fdtable() - we'll fail with EMFILE
+before that.
+
+Cc: stable@kernel.org # v2.6.25+
+Fixes: 9cfe015aa424 (get rid of NR_OPEN and introduce a sysctl_nr_open)
+Reported-by: Thiago Macieira <thiago.macieira@intel.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/file.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/file.c b/fs/file.c
+index 7e9eb65a2912..090015401c55 100644
+--- a/fs/file.c
++++ b/fs/file.c
+@@ -88,7 +88,7 @@ static void copy_fd_bitmaps(struct fdtable *nfdt, struct fdtable *ofdt,
+  */
+ static void copy_fdtable(struct fdtable *nfdt, struct fdtable *ofdt)
+ {
+-      unsigned int cpy, set;
++      size_t cpy, set;
+       BUG_ON(nfdt->max_fds < ofdt->max_fds);
+-- 
+2.25.1
+
diff --git a/queue-4.4/hid-multitouch-add-egalaxtouch-p80h84-support.patch b/queue-4.4/hid-multitouch-add-egalaxtouch-p80h84-support.patch
new file mode 100644 (file)
index 0000000..7350842
--- /dev/null
@@ -0,0 +1,53 @@
+From 78fa9fdce974156463350baaae2798ecb17990dd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Apr 2020 18:02:37 +0200
+Subject: HID: multitouch: add eGalaxTouch P80H84 support
+
+From: Sebastian Reichel <sebastian.reichel@collabora.com>
+
+[ Upstream commit f9e82295eec141a0569649d400d249333d74aa91 ]
+
+Add support for P80H84 touchscreen from eGalaxy:
+
+  idVendor           0x0eef D-WAV Scientific Co., Ltd
+  idProduct          0xc002
+  iManufacturer           1 eGalax Inc.
+  iProduct                2 eGalaxTouch P80H84 2019 vDIVA_1204_T01 k4.02.146
+
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hid/hid-ids.h        | 1 +
+ drivers/hid/hid-multitouch.c | 3 +++
+ 2 files changed, 4 insertions(+)
+
+diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
+index e1807296a1a0..33d2b5948d7f 100644
+--- a/drivers/hid/hid-ids.h
++++ b/drivers/hid/hid-ids.h
+@@ -319,6 +319,7 @@
+ #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_7349     0x7349
+ #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_73F7     0x73f7
+ #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001     0xa001
++#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002     0xc002
+ #define USB_VENDOR_ID_ELAN            0x04f3
+diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
+index 9de379c1b3fd..56c4a81d3ea2 100644
+--- a/drivers/hid/hid-multitouch.c
++++ b/drivers/hid/hid-multitouch.c
+@@ -1300,6 +1300,9 @@ static const struct hid_device_id mt_devices[] = {
+       { .driver_data = MT_CLS_EGALAX_SERIAL,
+               MT_USB_DEVICE(USB_VENDOR_ID_DWAV,
+                       USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001) },
++      { .driver_data = MT_CLS_EGALAX,
++              MT_USB_DEVICE(USB_VENDOR_ID_DWAV,
++                      USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002) },
+       /* Elitegroup panel */
+       { .driver_data = MT_CLS_SERIAL,
+-- 
+2.25.1
+
diff --git a/queue-4.4/platform-x86-asus-nb-wmi-do-not-load-on-asus-t100ta-.patch b/queue-4.4/platform-x86-asus-nb-wmi-do-not-load-on-asus-t100ta-.patch
new file mode 100644 (file)
index 0000000..2dfeaf2
--- /dev/null
@@ -0,0 +1,73 @@
+From 2270ab6a85b105ee4cfd672f480e8190040e5832 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 23 Apr 2020 00:05:59 +0200
+Subject: platform/x86: asus-nb-wmi: Do not load on Asus T100TA and T200TA
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+[ Upstream commit 3bd12da7f50b8bc191fcb3bab1f55c582234df59 ]
+
+asus-nb-wmi does not add any extra functionality on these Asus
+Transformer books. They have detachable keyboards, so the hotkeys are
+send through a HID device (and handled by the hid-asus driver) and also
+the rfkill functionality is not used on these devices.
+
+Besides not adding any extra functionality, initializing the WMI interface
+on these devices actually has a negative side-effect. For some reason
+the \_SB.ATKD.INIT() function which asus_wmi_platform_init() calls drives
+GPO2 (INT33FC:02) pin 8, which is connected to the front facing webcam LED,
+high and there is no (WMI or other) interface to drive this low again
+causing the LED to be permanently on, even during suspend.
+
+This commit adds a blacklist of DMI system_ids on which not to load the
+asus-nb-wmi and adds these Transformer books to this list. This fixes
+the webcam LED being permanently on under Linux.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/platform/x86/asus-nb-wmi.c | 24 ++++++++++++++++++++++++
+ 1 file changed, 24 insertions(+)
+
+diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
+index cccf250cd1e3..ee64c9512a3a 100644
+--- a/drivers/platform/x86/asus-nb-wmi.c
++++ b/drivers/platform/x86/asus-nb-wmi.c
+@@ -551,9 +551,33 @@ static struct asus_wmi_driver asus_nb_wmi_driver = {
+       .detect_quirks = asus_nb_wmi_quirks,
+ };
++static const struct dmi_system_id asus_nb_wmi_blacklist[] __initconst = {
++      {
++              /*
++               * asus-nb-wm adds no functionality. The T100TA has a detachable
++               * USB kbd, so no hotkeys and it has no WMI rfkill; and loading
++               * asus-nb-wm causes the camera LED to turn and _stay_ on.
++               */
++              .matches = {
++                      DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++                      DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TA"),
++              },
++      },
++      {
++              /* The Asus T200TA has the same issue as the T100TA */
++              .matches = {
++                      DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++                      DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T200TA"),
++              },
++      },
++      {} /* Terminating entry */
++};
+ static int __init asus_nb_wmi_init(void)
+ {
++      if (dmi_check_system(asus_nb_wmi_blacklist))
++              return -ENODEV;
++
+       return asus_wmi_register_driver(&asus_nb_wmi_driver);
+ }
+-- 
+2.25.1
+
index 531cdbf5b807839b71abf1d5fae0f89d7d5fc1df..138525bcaa1fbc5364ee598eabdeff6274fd1a4e 100644 (file)
@@ -1 +1,8 @@
 igb-use-igb_adapter-io_addr-instead-of-e1000_hw-hw_addr.patch
+evm-check-also-if-tfm-is-an-error-pointer-in-init_de.patch
+fix-multiplication-overflow-in-copy_fdtable.patch
+hid-multitouch-add-egalaxtouch-p80h84-support.patch
+ceph-fix-double-unlock-in-handle_cap_export.patch
+usb-core-fix-misleading-driver-bug-report.patch
+platform-x86-asus-nb-wmi-do-not-load-on-asus-t100ta-.patch
+arm-futex-address-build-warning.patch
diff --git a/queue-4.4/usb-core-fix-misleading-driver-bug-report.patch b/queue-4.4/usb-core-fix-misleading-driver-bug-report.patch
new file mode 100644 (file)
index 0000000..c9cea3f
--- /dev/null
@@ -0,0 +1,69 @@
+From 946fd6cf3f5a8241e074f7ba18f93629c1bb0f7e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 1 May 2020 16:07:28 -0400
+Subject: USB: core: Fix misleading driver bug report
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
+
+The syzbot fuzzer found a race between URB submission to endpoint 0
+and device reset.  Namely, during the reset we call usb_ep0_reinit()
+because the characteristics of ep0 may have changed (if the reset
+follows a firmware update, for example).  While usb_ep0_reinit() is
+running there is a brief period during which the pointers stored in
+udev->ep_in[0] and udev->ep_out[0] are set to NULL, and if an URB is
+submitted to ep0 during that period, usb_urb_ep_type_check() will
+report it as a driver bug.  In the absence of those pointers, the
+routine thinks that the endpoint doesn't exist.  The log message looks
+like this:
+
+------------[ cut here ]------------
+usb 2-1: BOGUS urb xfer, pipe 2 != type 2
+WARNING: CPU: 0 PID: 9241 at drivers/usb/core/urb.c:478
+usb_submit_urb+0x1188/0x1460 drivers/usb/core/urb.c:478
+
+Now, although submitting an URB while the device is being reset is a
+questionable thing to do, it shouldn't count as a driver bug as severe
+as submitting an URB for an endpoint that doesn't exist.  Indeed,
+endpoint 0 always exists, even while the device is in its unconfigured
+state.
+
+To prevent these misleading driver bug reports, this patch updates
+usb_disable_endpoint() to avoid clearing the ep_in[] and ep_out[]
+pointers when the endpoint being disabled is ep0.  There's no danger
+of leaving a stale pointer in place, because the usb_host_endpoint
+structure being pointed to is stored permanently in udev->ep0; it
+doesn't get deallocated until the entire usb_device structure does.
+
+Reported-and-tested-by: syzbot+db339689b2101f6f6071@syzkaller.appspotmail.com
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+
+Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2005011558590.903-100000@netrider.rowland.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/core/message.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
+index 747343c61398..f083ecfddd1b 100644
+--- a/drivers/usb/core/message.c
++++ b/drivers/usb/core/message.c
+@@ -1080,11 +1080,11 @@ void usb_disable_endpoint(struct usb_device *dev, unsigned int epaddr,
+       if (usb_endpoint_out(epaddr)) {
+               ep = dev->ep_out[epnum];
+-              if (reset_hardware)
++              if (reset_hardware && epnum != 0)
+                       dev->ep_out[epnum] = NULL;
+       } else {
+               ep = dev->ep_in[epnum];
+-              if (reset_hardware)
++              if (reset_hardware && epnum != 0)
+                       dev->ep_in[epnum] = NULL;
+       }
+       if (ep) {
+-- 
+2.25.1
+