From 846ffb8f45ca819eb622fc5febb8d15379fd9a95 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 12 May 2020 12:43:01 +0200 Subject: [PATCH] 5.4-stable patches added patches: crypto-arch-nhpoly1305-process-in-explicit-4k-chunks.patch hid-usbhid-fix-race-between-usbhid_close-and-usbhid_stop.patch hid-wacom-read-hid_dg_contactmax-directly-for-non-generic-devices.patch hid-wacom-report-2nd-gen-intuos-pro-s-center-button-status-over-bt.patch kvm-arm-vgic-fix-limit-condition-when-writing-to-gicd_iactiver.patch kvm-arm64-fix-32bit-pc-wrap-around.patch kvm-s390-remove-false-warn_on_once-for-the-pqap-instruction.patch kvm-vmx-explicitly-clear-rflags.cf-and-rflags.zf-in-vm-exit-rsb-path.patch revert-hid-wacom-generic-read-the-number-of-expected-touches-on-a-per-collection-basis.patch sctp-fix-bundling-of-shutdown-with-cookie-ack.patch tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch usb-chipidea-msm-ensure-proper-controller-reset-using-role-switch-api.patch usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch usb-uas-add-quirk-for-lacie-2big-quadra.patch --- ...ly1305-process-in-explicit-4k-chunks.patch | 75 ++++++++ ...between-usbhid_close-and-usbhid_stop.patch | 168 +++++++++++++++++ ...max-directly-for-non-generic-devices.patch | 48 +++++ ...s-pro-s-center-button-status-over-bt.patch | 54 ++++++ ...dition-when-writing-to-gicd_iactiver.patch | 49 +++++ .../kvm-arm64-fix-32bit-pc-wrap-around.patch | 72 ++++++++ ...arn_on_once-for-the-pqap-instruction.patch | 48 +++++ ...cf-and-rflags.zf-in-vm-exit-rsb-path.patch | 44 +++++ ...ed-touches-on-a-per-collection-basis.patch | 172 ++++++++++++++++++ ...bundling-of-shutdown-with-cookie-ack.patch | 69 +++++++ queue-5.4/series | 14 ++ ...alloc_sync_mappings-for-safe-measure.patch | 62 +++++++ ...ntroller-reset-using-role-switch-api.patch | 44 +++++ ...-add-sanity-checking-for-data-length.patch | 35 ++++ ...-uas-add-quirk-for-lacie-2big-quadra.patch | 41 +++++ 15 files changed, 995 insertions(+) create mode 100644 queue-5.4/crypto-arch-nhpoly1305-process-in-explicit-4k-chunks.patch create mode 100644 queue-5.4/hid-usbhid-fix-race-between-usbhid_close-and-usbhid_stop.patch create mode 100644 queue-5.4/hid-wacom-read-hid_dg_contactmax-directly-for-non-generic-devices.patch create mode 100644 queue-5.4/hid-wacom-report-2nd-gen-intuos-pro-s-center-button-status-over-bt.patch create mode 100644 queue-5.4/kvm-arm-vgic-fix-limit-condition-when-writing-to-gicd_iactiver.patch create mode 100644 queue-5.4/kvm-arm64-fix-32bit-pc-wrap-around.patch create mode 100644 queue-5.4/kvm-s390-remove-false-warn_on_once-for-the-pqap-instruction.patch create mode 100644 queue-5.4/kvm-vmx-explicitly-clear-rflags.cf-and-rflags.zf-in-vm-exit-rsb-path.patch create mode 100644 queue-5.4/revert-hid-wacom-generic-read-the-number-of-expected-touches-on-a-per-collection-basis.patch create mode 100644 queue-5.4/sctp-fix-bundling-of-shutdown-with-cookie-ack.patch create mode 100644 queue-5.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch create mode 100644 queue-5.4/usb-chipidea-msm-ensure-proper-controller-reset-using-role-switch-api.patch create mode 100644 queue-5.4/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch create mode 100644 queue-5.4/usb-uas-add-quirk-for-lacie-2big-quadra.patch diff --git a/queue-5.4/crypto-arch-nhpoly1305-process-in-explicit-4k-chunks.patch b/queue-5.4/crypto-arch-nhpoly1305-process-in-explicit-4k-chunks.patch new file mode 100644 index 00000000000..a7cd5950bc8 --- /dev/null +++ b/queue-5.4/crypto-arch-nhpoly1305-process-in-explicit-4k-chunks.patch @@ -0,0 +1,75 @@ +From a9a8ba90fa5857c2c8a0e32eef2159cec717da11 Mon Sep 17 00:00:00 2001 +From: "Jason A. Donenfeld" +Date: Wed, 22 Apr 2020 17:18:54 -0600 +Subject: crypto: arch/nhpoly1305 - process in explicit 4k chunks + +From: Jason A. Donenfeld + +commit a9a8ba90fa5857c2c8a0e32eef2159cec717da11 upstream. + +Rather than chunking via PAGE_SIZE, this commit changes the arch +implementations to chunk in explicit 4k parts, so that calculations on +maximum acceptable latency don't suddenly become invalid on platforms +where PAGE_SIZE isn't 4k, such as arm64. + +Fixes: 0f961f9f670e ("crypto: x86/nhpoly1305 - add AVX2 accelerated NHPoly1305") +Fixes: 012c82388c03 ("crypto: x86/nhpoly1305 - add SSE2 accelerated NHPoly1305") +Fixes: a00fa0c88774 ("crypto: arm64/nhpoly1305 - add NEON-accelerated NHPoly1305") +Fixes: 16aae3595a9d ("crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305") +Cc: stable@vger.kernel.org +Signed-off-by: Jason A. Donenfeld +Reviewed-by: Eric Biggers +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/crypto/nhpoly1305-neon-glue.c | 2 +- + arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +- + arch/x86/crypto/nhpoly1305-avx2-glue.c | 2 +- + arch/x86/crypto/nhpoly1305-sse2-glue.c | 2 +- + 4 files changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/arm/crypto/nhpoly1305-neon-glue.c ++++ b/arch/arm/crypto/nhpoly1305-neon-glue.c +@@ -30,7 +30,7 @@ static int nhpoly1305_neon_update(struct + return crypto_nhpoly1305_update(desc, src, srclen); + + do { +- unsigned int n = min_t(unsigned int, srclen, PAGE_SIZE); ++ unsigned int n = min_t(unsigned int, srclen, SZ_4K); + + kernel_neon_begin(); + crypto_nhpoly1305_update_helper(desc, src, n, _nh_neon); +--- a/arch/arm64/crypto/nhpoly1305-neon-glue.c ++++ b/arch/arm64/crypto/nhpoly1305-neon-glue.c +@@ -30,7 +30,7 @@ static int nhpoly1305_neon_update(struct + return crypto_nhpoly1305_update(desc, src, srclen); + + do { +- unsigned int n = min_t(unsigned int, srclen, PAGE_SIZE); ++ unsigned int n = min_t(unsigned int, srclen, SZ_4K); + + kernel_neon_begin(); + crypto_nhpoly1305_update_helper(desc, src, n, _nh_neon); +--- a/arch/x86/crypto/nhpoly1305-avx2-glue.c ++++ b/arch/x86/crypto/nhpoly1305-avx2-glue.c +@@ -29,7 +29,7 @@ static int nhpoly1305_avx2_update(struct + return crypto_nhpoly1305_update(desc, src, srclen); + + do { +- unsigned int n = min_t(unsigned int, srclen, PAGE_SIZE); ++ unsigned int n = min_t(unsigned int, srclen, SZ_4K); + + kernel_fpu_begin(); + crypto_nhpoly1305_update_helper(desc, src, n, _nh_avx2); +--- a/arch/x86/crypto/nhpoly1305-sse2-glue.c ++++ b/arch/x86/crypto/nhpoly1305-sse2-glue.c +@@ -29,7 +29,7 @@ static int nhpoly1305_sse2_update(struct + return crypto_nhpoly1305_update(desc, src, srclen); + + do { +- unsigned int n = min_t(unsigned int, srclen, PAGE_SIZE); ++ unsigned int n = min_t(unsigned int, srclen, SZ_4K); + + kernel_fpu_begin(); + crypto_nhpoly1305_update_helper(desc, src, n, _nh_sse2); diff --git a/queue-5.4/hid-usbhid-fix-race-between-usbhid_close-and-usbhid_stop.patch b/queue-5.4/hid-usbhid-fix-race-between-usbhid_close-and-usbhid_stop.patch new file mode 100644 index 00000000000..2de1ae35300 --- /dev/null +++ b/queue-5.4/hid-usbhid-fix-race-between-usbhid_close-and-usbhid_stop.patch @@ -0,0 +1,168 @@ +From 0ed08faded1da03eb3def61502b27f81aef2e615 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Wed, 22 Apr 2020 16:18:48 -0400 +Subject: HID: usbhid: Fix race between usbhid_close() and usbhid_stop() + +From: Alan Stern + +commit 0ed08faded1da03eb3def61502b27f81aef2e615 upstream. + +The syzbot fuzzer discovered a bad race between in the usbhid driver +between usbhid_stop() and usbhid_close(). In particular, +usbhid_stop() does: + + usb_free_urb(usbhid->urbin); + ... + usbhid->urbin = NULL; /* don't mess up next start */ + +and usbhid_close() does: + + usb_kill_urb(usbhid->urbin); + +with no mutual exclusion. If the two routines happen to run +concurrently so that usb_kill_urb() is called in between the +usb_free_urb() and the NULL assignment, it will access the +deallocated urb structure -- a use-after-free bug. + +This patch adds a mutex to the usbhid private structure and uses it to +enforce mutual exclusion of the usbhid_start(), usbhid_stop(), +usbhid_open() and usbhid_close() callbacks. + +Reported-and-tested-by: syzbot+7bf5a7b0f0a1f9446f4c@syzkaller.appspotmail.com +Signed-off-by: Alan Stern +CC: +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/usbhid/hid-core.c | 37 +++++++++++++++++++++++++++++-------- + drivers/hid/usbhid/usbhid.h | 1 + + 2 files changed, 30 insertions(+), 8 deletions(-) + +--- a/drivers/hid/usbhid/hid-core.c ++++ b/drivers/hid/usbhid/hid-core.c +@@ -682,16 +682,21 @@ static int usbhid_open(struct hid_device + struct usbhid_device *usbhid = hid->driver_data; + int res; + ++ mutex_lock(&usbhid->mutex); ++ + set_bit(HID_OPENED, &usbhid->iofl); + +- if (hid->quirks & HID_QUIRK_ALWAYS_POLL) +- return 0; ++ if (hid->quirks & HID_QUIRK_ALWAYS_POLL) { ++ res = 0; ++ goto Done; ++ } + + res = usb_autopm_get_interface(usbhid->intf); + /* the device must be awake to reliably request remote wakeup */ + if (res < 0) { + clear_bit(HID_OPENED, &usbhid->iofl); +- return -EIO; ++ res = -EIO; ++ goto Done; + } + + usbhid->intf->needs_remote_wakeup = 1; +@@ -725,6 +730,9 @@ static int usbhid_open(struct hid_device + msleep(50); + + clear_bit(HID_RESUME_RUNNING, &usbhid->iofl); ++ ++ Done: ++ mutex_unlock(&usbhid->mutex); + return res; + } + +@@ -732,6 +740,8 @@ static void usbhid_close(struct hid_devi + { + struct usbhid_device *usbhid = hid->driver_data; + ++ mutex_lock(&usbhid->mutex); ++ + /* + * Make sure we don't restart data acquisition due to + * a resumption we no longer care about by avoiding racing +@@ -743,12 +753,13 @@ static void usbhid_close(struct hid_devi + clear_bit(HID_IN_POLLING, &usbhid->iofl); + spin_unlock_irq(&usbhid->lock); + +- if (hid->quirks & HID_QUIRK_ALWAYS_POLL) +- return; ++ if (!(hid->quirks & HID_QUIRK_ALWAYS_POLL)) { ++ hid_cancel_delayed_stuff(usbhid); ++ usb_kill_urb(usbhid->urbin); ++ usbhid->intf->needs_remote_wakeup = 0; ++ } + +- hid_cancel_delayed_stuff(usbhid); +- usb_kill_urb(usbhid->urbin); +- usbhid->intf->needs_remote_wakeup = 0; ++ mutex_unlock(&usbhid->mutex); + } + + /* +@@ -1057,6 +1068,8 @@ static int usbhid_start(struct hid_devic + unsigned int n, insize = 0; + int ret; + ++ mutex_lock(&usbhid->mutex); ++ + clear_bit(HID_DISCONNECTED, &usbhid->iofl); + + usbhid->bufsize = HID_MIN_BUFFER_SIZE; +@@ -1177,6 +1190,8 @@ static int usbhid_start(struct hid_devic + usbhid_set_leds(hid); + device_set_wakeup_enable(&dev->dev, 1); + } ++ ++ mutex_unlock(&usbhid->mutex); + return 0; + + fail: +@@ -1187,6 +1202,7 @@ fail: + usbhid->urbout = NULL; + usbhid->urbctrl = NULL; + hid_free_buffers(dev, hid); ++ mutex_unlock(&usbhid->mutex); + return ret; + } + +@@ -1202,6 +1218,8 @@ static void usbhid_stop(struct hid_devic + usbhid->intf->needs_remote_wakeup = 0; + } + ++ mutex_lock(&usbhid->mutex); ++ + clear_bit(HID_STARTED, &usbhid->iofl); + spin_lock_irq(&usbhid->lock); /* Sync with error and led handlers */ + set_bit(HID_DISCONNECTED, &usbhid->iofl); +@@ -1222,6 +1240,8 @@ static void usbhid_stop(struct hid_devic + usbhid->urbout = NULL; + + hid_free_buffers(hid_to_usb_dev(hid), hid); ++ ++ mutex_unlock(&usbhid->mutex); + } + + static int usbhid_power(struct hid_device *hid, int lvl) +@@ -1382,6 +1402,7 @@ static int usbhid_probe(struct usb_inter + INIT_WORK(&usbhid->reset_work, hid_reset); + timer_setup(&usbhid->io_retry, hid_retry_timeout, 0); + spin_lock_init(&usbhid->lock); ++ mutex_init(&usbhid->mutex); + + ret = hid_add_device(hid); + if (ret) { +--- a/drivers/hid/usbhid/usbhid.h ++++ b/drivers/hid/usbhid/usbhid.h +@@ -80,6 +80,7 @@ struct usbhid_device { + dma_addr_t outbuf_dma; /* Output buffer dma */ + unsigned long last_out; /* record of last output for timeouts */ + ++ struct mutex mutex; /* start/stop/open/close */ + spinlock_t lock; /* fifo spinlock */ + unsigned long iofl; /* I/O flags (CTRL_RUNNING, OUT_RUNNING) */ + struct timer_list io_retry; /* Retry timer */ diff --git a/queue-5.4/hid-wacom-read-hid_dg_contactmax-directly-for-non-generic-devices.patch b/queue-5.4/hid-wacom-read-hid_dg_contactmax-directly-for-non-generic-devices.patch new file mode 100644 index 00000000000..a78a2504712 --- /dev/null +++ b/queue-5.4/hid-wacom-read-hid_dg_contactmax-directly-for-non-generic-devices.patch @@ -0,0 +1,48 @@ +From 778fbf4179991e7652e97d7f1ca1f657ef828422 Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Wed, 1 Apr 2020 14:23:29 -0700 +Subject: HID: wacom: Read HID_DG_CONTACTMAX directly for non-generic devices + +From: Jason Gerecke + +commit 778fbf4179991e7652e97d7f1ca1f657ef828422 upstream. + +We've recently switched from extracting the value of HID_DG_CONTACTMAX +at a fixed offset (which may not be correct for all tablets) to +injecting the report into the driver for the generic codepath to handle. +Unfortunately, this change was made for *all* tablets, even those which +aren't generic. Because `wacom_wac_report` ignores reports from non- +generic devices, the contact count never gets initialized. Ultimately +this results in the touch device itself failing to probe, and thus the +loss of touch input. + +This commit adds back the fixed-offset extraction for non-generic devices. + +Link: https://github.com/linuxwacom/input-wacom/issues/155 +Fixes: 184eccd40389 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report") +Signed-off-by: Jason Gerecke +Reviewed-by: Aaron Armstrong Skomra +CC: stable@vger.kernel.org # 5.3+ +Signed-off-by: Benjamin Tissoires +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/wacom_sys.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/hid/wacom_sys.c ++++ b/drivers/hid/wacom_sys.c +@@ -319,9 +319,11 @@ static void wacom_feature_mapping(struct + data[0] = field->report->id; + ret = wacom_get_report(hdev, HID_FEATURE_REPORT, + data, n, WAC_CMD_RETRIES); +- if (ret == n) { ++ if (ret == n && features->type == HID_GENERIC) { + ret = hid_report_raw_event(hdev, + HID_FEATURE_REPORT, data, n, 0); ++ } else if (ret == 2 && features->type != HID_GENERIC) { ++ features->touch_max = data[1]; + } else { + features->touch_max = 16; + hid_warn(hdev, "wacom_feature_mapping: " diff --git a/queue-5.4/hid-wacom-report-2nd-gen-intuos-pro-s-center-button-status-over-bt.patch b/queue-5.4/hid-wacom-report-2nd-gen-intuos-pro-s-center-button-status-over-bt.patch new file mode 100644 index 00000000000..b7fb0c4f2a5 --- /dev/null +++ b/queue-5.4/hid-wacom-report-2nd-gen-intuos-pro-s-center-button-status-over-bt.patch @@ -0,0 +1,54 @@ +From dcce8ef8f70a8e38e6c47c1bae8b312376c04420 Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Fri, 24 Apr 2020 14:04:00 -0700 +Subject: HID: wacom: Report 2nd-gen Intuos Pro S center button status over BT + +From: Jason Gerecke + +commit dcce8ef8f70a8e38e6c47c1bae8b312376c04420 upstream. + +The state of the center button was not reported to userspace for the +2nd-gen Intuos Pro S when used over Bluetooth due to the pad handling +code not being updated to support its reduced number of buttons. This +patch uses the actual number of buttons present on the tablet to +assemble a button state bitmap. + +Link: https://github.com/linuxwacom/xf86-input-wacom/issues/112 +Fixes: cd47de45b855 ("HID: wacom: Add 2nd gen Intuos Pro Small support") +Signed-off-by: Jason Gerecke +Cc: stable@vger.kernel.org # v5.3+ +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/wacom_wac.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -1427,11 +1427,13 @@ static void wacom_intuos_pro2_bt_pad(str + { + struct input_dev *pad_input = wacom->pad_input; + unsigned char *data = wacom->data; ++ int nbuttons = wacom->features.numbered_buttons; + +- int buttons = data[282] | ((data[281] & 0x40) << 2); ++ int expresskeys = data[282]; ++ int center = (data[281] & 0x40) >> 6; + int ring = data[285] & 0x7F; + bool ringstatus = data[285] & 0x80; +- bool prox = buttons || ringstatus; ++ bool prox = expresskeys || center || ringstatus; + + /* Fix touchring data: userspace expects 0 at left and increasing clockwise */ + ring = 71 - ring; +@@ -1439,7 +1441,8 @@ static void wacom_intuos_pro2_bt_pad(str + if (ring > 71) + ring -= 72; + +- wacom_report_numbered_buttons(pad_input, 9, buttons); ++ wacom_report_numbered_buttons(pad_input, nbuttons, ++ expresskeys | (center << (nbuttons - 1))); + + input_report_abs(pad_input, ABS_WHEEL, ringstatus ? ring : 0); + diff --git a/queue-5.4/kvm-arm-vgic-fix-limit-condition-when-writing-to-gicd_iactiver.patch b/queue-5.4/kvm-arm-vgic-fix-limit-condition-when-writing-to-gicd_iactiver.patch new file mode 100644 index 00000000000..cd5a6c2eae7 --- /dev/null +++ b/queue-5.4/kvm-arm-vgic-fix-limit-condition-when-writing-to-gicd_iactiver.patch @@ -0,0 +1,49 @@ +From 1c32ca5dc6d00012f0c964e5fdd7042fcc71efb1 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Tue, 14 Apr 2020 15:10:08 +0100 +Subject: KVM: arm: vgic: Fix limit condition when writing to GICD_I[CS]ACTIVER +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +commit 1c32ca5dc6d00012f0c964e5fdd7042fcc71efb1 upstream. + +When deciding whether a guest has to be stopped we check whether this +is a private interrupt or not. Unfortunately, there's an off-by-one bug +here, and we fail to recognize a whole range of interrupts as being +global (GICv2 SPIs 32-63). + +Fix the condition from > to be >=. + +Cc: stable@vger.kernel.org +Fixes: abd7229626b93 ("KVM: arm/arm64: Simplify active_change_prepare and plug race") +Reported-by: André Przywara +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + virt/kvm/arm/vgic/vgic-mmio.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/virt/kvm/arm/vgic/vgic-mmio.c ++++ b/virt/kvm/arm/vgic/vgic-mmio.c +@@ -389,7 +389,7 @@ static void vgic_mmio_change_active(stru + static void vgic_change_active_prepare(struct kvm_vcpu *vcpu, u32 intid) + { + if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3 || +- intid > VGIC_NR_PRIVATE_IRQS) ++ intid >= VGIC_NR_PRIVATE_IRQS) + kvm_arm_halt_guest(vcpu->kvm); + } + +@@ -397,7 +397,7 @@ static void vgic_change_active_prepare(s + static void vgic_change_active_finish(struct kvm_vcpu *vcpu, u32 intid) + { + if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3 || +- intid > VGIC_NR_PRIVATE_IRQS) ++ intid >= VGIC_NR_PRIVATE_IRQS) + kvm_arm_resume_guest(vcpu->kvm); + } + diff --git a/queue-5.4/kvm-arm64-fix-32bit-pc-wrap-around.patch b/queue-5.4/kvm-arm64-fix-32bit-pc-wrap-around.patch new file mode 100644 index 00000000000..cb86c69a664 --- /dev/null +++ b/queue-5.4/kvm-arm64-fix-32bit-pc-wrap-around.patch @@ -0,0 +1,72 @@ +From 0225fd5e0a6a32af7af0aefac45c8ebf19dc5183 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Wed, 29 Apr 2020 11:21:55 +0100 +Subject: KVM: arm64: Fix 32bit PC wrap-around + +From: Marc Zyngier + +commit 0225fd5e0a6a32af7af0aefac45c8ebf19dc5183 upstream. + +In the unlikely event that a 32bit vcpu traps into the hypervisor +on an instruction that is located right at the end of the 32bit +range, the emulation of that instruction is going to increment +PC past the 32bit range. This isn't great, as userspace can then +observe this value and get a bit confused. + +Conversly, userspace can do things like (in the context of a 64bit +guest that is capable of 32bit EL0) setting PSTATE to AArch64-EL0, +set PC to a 64bit value, change PSTATE to AArch32-USR, and observe +that PC hasn't been truncated. More confusion. + +Fix both by: +- truncating PC increments for 32bit guests +- sanitizing all 32bit regs every time a core reg is changed by + userspace, and that PSTATE indicates a 32bit mode. + +Cc: stable@vger.kernel.org +Acked-by: Will Deacon +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/kvm/guest.c | 7 +++++++ + virt/kvm/arm/hyp/aarch32.c | 8 ++++++-- + 2 files changed, 13 insertions(+), 2 deletions(-) + +--- a/arch/arm64/kvm/guest.c ++++ b/arch/arm64/kvm/guest.c +@@ -202,6 +202,13 @@ static int set_core_reg(struct kvm_vcpu + } + + memcpy((u32 *)regs + off, valp, KVM_REG_SIZE(reg->id)); ++ ++ if (*vcpu_cpsr(vcpu) & PSR_MODE32_BIT) { ++ int i; ++ ++ for (i = 0; i < 16; i++) ++ *vcpu_reg32(vcpu, i) = (u32)*vcpu_reg32(vcpu, i); ++ } + out: + return err; + } +--- a/virt/kvm/arm/hyp/aarch32.c ++++ b/virt/kvm/arm/hyp/aarch32.c +@@ -125,12 +125,16 @@ static void __hyp_text kvm_adjust_itstat + */ + void __hyp_text kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr) + { ++ u32 pc = *vcpu_pc(vcpu); + bool is_thumb; + + is_thumb = !!(*vcpu_cpsr(vcpu) & PSR_AA32_T_BIT); + if (is_thumb && !is_wide_instr) +- *vcpu_pc(vcpu) += 2; ++ pc += 2; + else +- *vcpu_pc(vcpu) += 4; ++ pc += 4; ++ ++ *vcpu_pc(vcpu) = pc; ++ + kvm_adjust_itstate(vcpu); + } diff --git a/queue-5.4/kvm-s390-remove-false-warn_on_once-for-the-pqap-instruction.patch b/queue-5.4/kvm-s390-remove-false-warn_on_once-for-the-pqap-instruction.patch new file mode 100644 index 00000000000..4738a7fab55 --- /dev/null +++ b/queue-5.4/kvm-s390-remove-false-warn_on_once-for-the-pqap-instruction.patch @@ -0,0 +1,48 @@ +From 5615e74f48dcc982655543e979b6c3f3f877e6f6 Mon Sep 17 00:00:00 2001 +From: Christian Borntraeger +Date: Tue, 5 May 2020 09:27:15 +0200 +Subject: KVM: s390: Remove false WARN_ON_ONCE for the PQAP instruction + +From: Christian Borntraeger + +commit 5615e74f48dcc982655543e979b6c3f3f877e6f6 upstream. + +In LPAR we will only get an intercept for FC==3 for the PQAP +instruction. Running nested under z/VM can result in other intercepts as +well as ECA_APIE is an effective bit: If one hypervisor layer has +turned this bit off, the end result will be that we will get intercepts for +all function codes. Usually the first one will be a query like PQAP(QCI). +So the WARN_ON_ONCE is not right. Let us simply remove it. + +Cc: Pierre Morel +Cc: Tony Krowiak +Cc: stable@vger.kernel.org # v5.3+ +Fixes: e5282de93105 ("s390: ap: kvm: add PQAP interception for AQIC") +Link: https://lore.kernel.org/kvm/20200505083515.2720-1-borntraeger@de.ibm.com +Reported-by: Qian Cai +Signed-off-by: Christian Borntraeger +Reviewed-by: David Hildenbrand +Reviewed-by: Cornelia Huck +Signed-off-by: Christian Borntraeger +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kvm/priv.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/s390/kvm/priv.c ++++ b/arch/s390/kvm/priv.c +@@ -626,10 +626,12 @@ static int handle_pqap(struct kvm_vcpu * + * available for the guest are AQIC and TAPQ with the t bit set + * since we do not set IC.3 (FIII) we currently will only intercept + * the AQIC function code. ++ * Note: running nested under z/VM can result in intercepts for other ++ * function codes, e.g. PQAP(QCI). We do not support this and bail out. + */ + reg0 = vcpu->run->s.regs.gprs[0]; + fc = (reg0 >> 24) & 0xff; +- if (WARN_ON_ONCE(fc != 0x03)) ++ if (fc != 0x03) + return -EOPNOTSUPP; + + /* PQAP instruction is allowed for guest kernel only */ diff --git a/queue-5.4/kvm-vmx-explicitly-clear-rflags.cf-and-rflags.zf-in-vm-exit-rsb-path.patch b/queue-5.4/kvm-vmx-explicitly-clear-rflags.cf-and-rflags.zf-in-vm-exit-rsb-path.patch new file mode 100644 index 00000000000..039869e21d1 --- /dev/null +++ b/queue-5.4/kvm-vmx-explicitly-clear-rflags.cf-and-rflags.zf-in-vm-exit-rsb-path.patch @@ -0,0 +1,44 @@ +From c7cb2d650c9e78c03bd2d1c0db89891825f8c0f4 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 5 May 2020 20:53:55 -0700 +Subject: KVM: VMX: Explicitly clear RFLAGS.CF and RFLAGS.ZF in VM-Exit RSB path + +From: Sean Christopherson + +commit c7cb2d650c9e78c03bd2d1c0db89891825f8c0f4 upstream. + +Clear CF and ZF in the VM-Exit path after doing __FILL_RETURN_BUFFER so +that KVM doesn't interpret clobbered RFLAGS as a VM-Fail. Filling the +RSB has always clobbered RFLAGS, its current incarnation just happens +clear CF and ZF in the processs. Relying on the macro to clear CF and +ZF is extremely fragile, e.g. commit 089dd8e53126e ("x86/speculation: +Change FILL_RETURN_BUFFER to work with objtool") tweaks the loop such +that the ZF flag is always set. + +Reported-by: Qian Cai +Cc: Rick Edgecombe +Cc: Peter Zijlstra (Intel) +Cc: Josh Poimboeuf +Cc: stable@vger.kernel.org +Fixes: f2fde6a5bcfcf ("KVM: VMX: Move RSB stuffing to before the first RET after VM-Exit") +Signed-off-by: Sean Christopherson +Message-Id: <20200506035355.2242-1-sean.j.christopherson@intel.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx/vmenter.S | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kvm/vmx/vmenter.S ++++ b/arch/x86/kvm/vmx/vmenter.S +@@ -86,6 +86,9 @@ ENTRY(vmx_vmexit) + /* IMPORTANT: Stuff the RSB immediately after VM-Exit, before RET! */ + FILL_RETURN_BUFFER %_ASM_AX, RSB_CLEAR_LOOPS, X86_FEATURE_RETPOLINE + ++ /* Clear RFLAGS.CF and RFLAGS.ZF to preserve VM-Exit, i.e. !VM-Fail. */ ++ or $1, %_ASM_AX ++ + pop %_ASM_AX + .Lvmexit_skip_rsb: + #endif diff --git a/queue-5.4/revert-hid-wacom-generic-read-the-number-of-expected-touches-on-a-per-collection-basis.patch b/queue-5.4/revert-hid-wacom-generic-read-the-number-of-expected-touches-on-a-per-collection-basis.patch new file mode 100644 index 00000000000..50b6987d663 --- /dev/null +++ b/queue-5.4/revert-hid-wacom-generic-read-the-number-of-expected-touches-on-a-per-collection-basis.patch @@ -0,0 +1,172 @@ +From b43f977dd281945960c26b3ef67bba0fa07d39d9 Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Wed, 8 Apr 2020 07:58:37 -0700 +Subject: Revert "HID: wacom: generic: read the number of expected touches on a per collection basis" + +From: Jason Gerecke + +commit b43f977dd281945960c26b3ef67bba0fa07d39d9 upstream. + +This reverts commit 15893fa40109f5e7c67eeb8da62267d0fdf0be9d. + +The referenced commit broke pen and touch input for a variety of devices +such as the Cintiq Pro 32. Affected devices may appear to work normally +for a short amount of time, but eventually loose track of actual touch +state and can leave touch arbitration enabled which prevents the pen +from working. The commit is not itself required for any currently-available +Bluetooth device, and so we revert it to correct the behavior of broken +devices. + +This breakage occurs due to a mismatch between the order of collections +and the order of usages on some devices. This commit tries to read the +contact count before processing events, but will fail if the contact +count does not occur prior to the first logical finger collection. This +is the case for devices like the Cintiq Pro 32 which place the contact +count at the very end of the report. + +Without the contact count set, touches will only be partially processed. +The `wacom_wac_finger_slot` function will not open any slots since the +number of contacts seen is greater than the expectation of 0, but we will +still end up calling `input_mt_sync_frame` for each finger anyway. This +can cause problems for userspace separate from the issue currently taking +place in the kernel. Only once all of the individual finger collections +have been processed do we finally get to the enclosing collection which +contains the contact count. The value ends up being used for the *next* +report, however. + +This delayed use of the contact count can cause the driver to loose track +of the actual touch state and believe that there are contacts down when +there aren't. This leaves touch arbitration enabled and prevents the pen +from working. It can also cause userspace to incorrectly treat single- +finger input as gestures. + +Link: https://github.com/linuxwacom/input-wacom/issues/146 +Signed-off-by: Jason Gerecke +Reviewed-by: Aaron Armstrong Skomra +Fixes: 15893fa40109 ("HID: wacom: generic: read the number of expected touches on a per collection basis") +Cc: stable@vger.kernel.org # 5.3+ +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/wacom_wac.c | 79 +++++++++--------------------------------------- + 1 file changed, 16 insertions(+), 63 deletions(-) + +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -2637,9 +2637,25 @@ static void wacom_wac_finger_pre_report( + case HID_DG_TIPSWITCH: + hid_data->last_slot_field = equivalent_usage; + break; ++ case HID_DG_CONTACTCOUNT: ++ hid_data->cc_report = report->id; ++ hid_data->cc_index = i; ++ hid_data->cc_value_index = j; ++ break; + } + } + } ++ ++ if (hid_data->cc_report != 0 && ++ hid_data->cc_index >= 0) { ++ struct hid_field *field = report->field[hid_data->cc_index]; ++ int value = field->value[hid_data->cc_value_index]; ++ if (value) ++ hid_data->num_expected = value; ++ } ++ else { ++ hid_data->num_expected = wacom_wac->features.touch_max; ++ } + } + + static void wacom_wac_finger_report(struct hid_device *hdev, +@@ -2649,7 +2665,6 @@ static void wacom_wac_finger_report(stru + struct wacom_wac *wacom_wac = &wacom->wacom_wac; + struct input_dev *input = wacom_wac->touch_input; + unsigned touch_max = wacom_wac->features.touch_max; +- struct hid_data *hid_data = &wacom_wac->hid_data; + + /* If more packets of data are expected, give us a chance to + * process them rather than immediately syncing a partial +@@ -2663,7 +2678,6 @@ static void wacom_wac_finger_report(stru + + input_sync(input); + wacom_wac->hid_data.num_received = 0; +- hid_data->num_expected = 0; + + /* keep touch state for pen event */ + wacom_wac->shared->touch_down = wacom_wac_finger_count_touches(wacom_wac); +@@ -2738,73 +2752,12 @@ static void wacom_report_events(struct h + } + } + +-static void wacom_set_num_expected(struct hid_device *hdev, +- struct hid_report *report, +- int collection_index, +- struct hid_field *field, +- int field_index) +-{ +- struct wacom *wacom = hid_get_drvdata(hdev); +- struct wacom_wac *wacom_wac = &wacom->wacom_wac; +- struct hid_data *hid_data = &wacom_wac->hid_data; +- unsigned int original_collection_level = +- hdev->collection[collection_index].level; +- bool end_collection = false; +- int i; +- +- if (hid_data->num_expected) +- return; +- +- // find the contact count value for this segment +- for (i = field_index; i < report->maxfield && !end_collection; i++) { +- struct hid_field *field = report->field[i]; +- unsigned int field_level = +- hdev->collection[field->usage[0].collection_index].level; +- unsigned int j; +- +- if (field_level != original_collection_level) +- continue; +- +- for (j = 0; j < field->maxusage; j++) { +- struct hid_usage *usage = &field->usage[j]; +- +- if (usage->collection_index != collection_index) { +- end_collection = true; +- break; +- } +- if (wacom_equivalent_usage(usage->hid) == HID_DG_CONTACTCOUNT) { +- hid_data->cc_report = report->id; +- hid_data->cc_index = i; +- hid_data->cc_value_index = j; +- +- if (hid_data->cc_report != 0 && +- hid_data->cc_index >= 0) { +- +- struct hid_field *field = +- report->field[hid_data->cc_index]; +- int value = +- field->value[hid_data->cc_value_index]; +- +- if (value) +- hid_data->num_expected = value; +- } +- } +- } +- } +- +- if (hid_data->cc_report == 0 || hid_data->cc_index < 0) +- hid_data->num_expected = wacom_wac->features.touch_max; +-} +- + static int wacom_wac_collection(struct hid_device *hdev, struct hid_report *report, + int collection_index, struct hid_field *field, + int field_index) + { + struct wacom *wacom = hid_get_drvdata(hdev); + +- if (WACOM_FINGER_FIELD(field)) +- wacom_set_num_expected(hdev, report, collection_index, field, +- field_index); + wacom_report_events(hdev, report, collection_index, field_index); + + /* diff --git a/queue-5.4/sctp-fix-bundling-of-shutdown-with-cookie-ack.patch b/queue-5.4/sctp-fix-bundling-of-shutdown-with-cookie-ack.patch new file mode 100644 index 00000000000..ee88d455e97 --- /dev/null +++ b/queue-5.4/sctp-fix-bundling-of-shutdown-with-cookie-ack.patch @@ -0,0 +1,69 @@ +From 145cb2f7177d94bc54563ed26027e952ee0ae03c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Jere=20Lepp=C3=A4nen?= +Date: Tue, 21 Apr 2020 22:03:41 +0300 +Subject: sctp: Fix bundling of SHUTDOWN with COOKIE-ACK +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jere Leppänen + +commit 145cb2f7177d94bc54563ed26027e952ee0ae03c upstream. + +When we start shutdown in sctp_sf_do_dupcook_a(), we want to bundle +the SHUTDOWN with the COOKIE-ACK to ensure that the peer receives them +at the same time and in the correct order. This bundling was broken by +commit 4ff40b86262b ("sctp: set chunk transport correctly when it's a +new asoc"), which assigns a transport for the COOKIE-ACK, but not for +the SHUTDOWN. + +Fix this by passing a reference to the COOKIE-ACK chunk as an argument +to sctp_sf_do_9_2_start_shutdown() and onward to +sctp_make_shutdown(). This way the SHUTDOWN chunk is assigned the same +transport as the COOKIE-ACK chunk, which allows them to be bundled. + +In sctp_sf_do_9_2_start_shutdown(), the void *arg parameter was +previously unused. Now that we're taking it into use, it must be a +valid pointer to a chunk, or NULL. There is only one call site where +it's not, in sctp_sf_autoclose_timer_expire(). Fix that too. + +Fixes: 4ff40b86262b ("sctp: set chunk transport correctly when it's a new asoc") +Signed-off-by: Jere Leppänen +Acked-by: Marcelo Ricardo Leitner +Signed-off-by: David S. Miller +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + net/sctp/sm_statefuns.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/net/sctp/sm_statefuns.c ++++ b/net/sctp/sm_statefuns.c +@@ -1865,7 +1865,7 @@ static enum sctp_disposition sctp_sf_do_ + */ + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl)); + return sctp_sf_do_9_2_start_shutdown(net, ep, asoc, +- SCTP_ST_CHUNK(0), NULL, ++ SCTP_ST_CHUNK(0), repl, + commands); + } else { + sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE, +@@ -5470,7 +5470,7 @@ enum sctp_disposition sctp_sf_do_9_2_sta + * in the Cumulative TSN Ack field the last sequential TSN it + * has received from the peer. + */ +- reply = sctp_make_shutdown(asoc, NULL); ++ reply = sctp_make_shutdown(asoc, arg); + if (!reply) + goto nomem; + +@@ -6068,7 +6068,7 @@ enum sctp_disposition sctp_sf_autoclose_ + disposition = SCTP_DISPOSITION_CONSUME; + if (sctp_outq_is_empty(&asoc->outqueue)) { + disposition = sctp_sf_do_9_2_start_shutdown(net, ep, asoc, type, +- arg, commands); ++ NULL, commands); + } + + return disposition; diff --git a/queue-5.4/series b/queue-5.4/series index 988a9e5f46e..a9e44c4f080 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -38,3 +38,17 @@ net-mlx5-fix-forced-completion-access-non-initialized-command-entry.patch net-mlx5-fix-command-entry-leak-in-internal-error-state.patch net-mvpp2-prevent-buffer-overflow-in-mvpp22_rss_ctx.patch net-mvpp2-cls-prevent-buffer-overflow-in-mvpp2_ethtool_cls_rule_del.patch +hid-wacom-read-hid_dg_contactmax-directly-for-non-generic-devices.patch +sctp-fix-bundling-of-shutdown-with-cookie-ack.patch +revert-hid-wacom-generic-read-the-number-of-expected-touches-on-a-per-collection-basis.patch +hid-usbhid-fix-race-between-usbhid_close-and-usbhid_stop.patch +hid-wacom-report-2nd-gen-intuos-pro-s-center-button-status-over-bt.patch +usb-uas-add-quirk-for-lacie-2big-quadra.patch +usb-chipidea-msm-ensure-proper-controller-reset-using-role-switch-api.patch +usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch +tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch +crypto-arch-nhpoly1305-process-in-explicit-4k-chunks.patch +kvm-s390-remove-false-warn_on_once-for-the-pqap-instruction.patch +kvm-vmx-explicitly-clear-rflags.cf-and-rflags.zf-in-vm-exit-rsb-path.patch +kvm-arm-vgic-fix-limit-condition-when-writing-to-gicd_iactiver.patch +kvm-arm64-fix-32bit-pc-wrap-around.patch diff --git a/queue-5.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch b/queue-5.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch new file mode 100644 index 00000000000..b8f943d04c0 --- /dev/null +++ b/queue-5.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch @@ -0,0 +1,62 @@ +From 11f5efc3ab66284f7aaacc926e9351d658e2577b Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (VMware)" +Date: Wed, 6 May 2020 10:36:18 -0400 +Subject: tracing: Add a vmalloc_sync_mappings() for safe measure + +From: Steven Rostedt (VMware) + +commit 11f5efc3ab66284f7aaacc926e9351d658e2577b upstream. + +x86_64 lazily maps in the vmalloc pages, and the way this works with per_cpu +areas can be complex, to say the least. Mappings may happen at boot up, and +if nothing synchronizes the page tables, those page mappings may not be +synced till they are used. This causes issues for anything that might touch +one of those mappings in the path of the page fault handler. When one of +those unmapped mappings is touched in the page fault handler, it will cause +another page fault, which in turn will cause a page fault, and leave us in +a loop of page faults. + +Commit 763802b53a42 ("x86/mm: split vmalloc_sync_all()") split +vmalloc_sync_all() into vmalloc_sync_unmappings() and +vmalloc_sync_mappings(), as on system exit, it did not need to do a full +sync on x86_64 (although it still needed to be done on x86_32). By chance, +the vmalloc_sync_all() would synchronize the page mappings done at boot up +and prevent the per cpu area from being a problem for tracing in the page +fault handler. But when that synchronization in the exit of a task became a +nop, it caused the problem to appear. + +Link: https://lore.kernel.org/r/20200429054857.66e8e333@oasis.local.home + +Cc: stable@vger.kernel.org +Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code") +Reported-by: "Tzvetomir Stoyanov (VMware)" +Suggested-by: Joerg Roedel +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -8318,6 +8318,19 @@ static int allocate_trace_buffers(struct + */ + allocate_snapshot = false; + #endif ++ ++ /* ++ * Because of some magic with the way alloc_percpu() works on ++ * x86_64, we need to synchronize the pgd of all the tables, ++ * otherwise the trace events that happen in x86_64 page fault ++ * handlers can't cope with accessing the chance that a ++ * alloc_percpu()'d memory might be touched in the page fault trace ++ * event. Oh, and we need to audit all other alloc_percpu() and vmalloc() ++ * calls in tracing, because something might get triggered within a ++ * page fault trace event! ++ */ ++ vmalloc_sync_mappings(); ++ + return 0; + } + diff --git a/queue-5.4/usb-chipidea-msm-ensure-proper-controller-reset-using-role-switch-api.patch b/queue-5.4/usb-chipidea-msm-ensure-proper-controller-reset-using-role-switch-api.patch new file mode 100644 index 00000000000..30fd4749732 --- /dev/null +++ b/queue-5.4/usb-chipidea-msm-ensure-proper-controller-reset-using-role-switch-api.patch @@ -0,0 +1,44 @@ +From 91edf63d5022bd0464788ffb4acc3d5febbaf81d Mon Sep 17 00:00:00 2001 +From: Bryan O'Donoghue +Date: Thu, 7 May 2020 08:49:18 +0800 +Subject: usb: chipidea: msm: Ensure proper controller reset using role switch API + +From: Bryan O'Donoghue + +commit 91edf63d5022bd0464788ffb4acc3d5febbaf81d upstream. + +Currently we check to make sure there is no error state on the extcon +handle for VBUS when writing to the HS_PHY_GENCONFIG_2 register. When using +the USB role-switch API we still need to write to this register absent an +extcon handle. + +This patch makes the appropriate update to ensure the write happens if +role-switching is true. + +Fixes: 05559f10ed79 ("usb: chipidea: add role switch class support") +Cc: stable +Cc: Greg Kroah-Hartman +Cc: Philipp Zabel +Cc: linux-usb@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Cc: Stephen Boyd +Signed-off-by: Bryan O'Donoghue +Signed-off-by: Peter Chen +Link: https://lore.kernel.org/r/20200507004918.25975-2-peter.chen@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/chipidea/ci_hdrc_msm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/chipidea/ci_hdrc_msm.c ++++ b/drivers/usb/chipidea/ci_hdrc_msm.c +@@ -114,7 +114,7 @@ static int ci_hdrc_msm_notify_event(stru + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2, + HS_PHY_ULPI_TX_PKT_EN_CLR_FIX, 0); + +- if (!IS_ERR(ci->platdata->vbus_extcon.edev)) { ++ if (!IS_ERR(ci->platdata->vbus_extcon.edev) || ci->role_switch) { + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2, + HS_PHY_SESS_VLD_CTRL_EN, + HS_PHY_SESS_VLD_CTRL_EN); diff --git a/queue-5.4/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch b/queue-5.4/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch new file mode 100644 index 00000000000..5537cffa167 --- /dev/null +++ b/queue-5.4/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch @@ -0,0 +1,35 @@ +From e9b3c610a05c1cdf8e959a6d89c38807ff758ee6 Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Wed, 15 Apr 2020 16:03:04 +0200 +Subject: USB: serial: garmin_gps: add sanity checking for data length + +From: Oliver Neukum + +commit e9b3c610a05c1cdf8e959a6d89c38807ff758ee6 upstream. + +We must not process packets shorter than a packet ID + +Signed-off-by: Oliver Neukum +Reported-and-tested-by: syzbot+d29e9263e13ce0b9f4fd@syzkaller.appspotmail.com +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Cc: stable +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/serial/garmin_gps.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/usb/serial/garmin_gps.c ++++ b/drivers/usb/serial/garmin_gps.c +@@ -1138,8 +1138,8 @@ static void garmin_read_process(struct g + send it directly to the tty port */ + if (garmin_data_p->flags & FLAGS_QUEUING) { + pkt_add(garmin_data_p, data, data_length); +- } else if (bulk_data || +- getLayerId(data) == GARMIN_LAYERID_APPL) { ++ } else if (bulk_data || (data_length >= sizeof(u32) && ++ getLayerId(data) == GARMIN_LAYERID_APPL)) { + + spin_lock_irqsave(&garmin_data_p->lock, flags); + garmin_data_p->flags |= APP_RESP_SEEN; diff --git a/queue-5.4/usb-uas-add-quirk-for-lacie-2big-quadra.patch b/queue-5.4/usb-uas-add-quirk-for-lacie-2big-quadra.patch new file mode 100644 index 00000000000..dfe8eb238ef --- /dev/null +++ b/queue-5.4/usb-uas-add-quirk-for-lacie-2big-quadra.patch @@ -0,0 +1,41 @@ +From 9f04db234af691007bb785342a06abab5fb34474 Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Wed, 29 Apr 2020 17:52:18 +0200 +Subject: USB: uas: add quirk for LaCie 2Big Quadra +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Oliver Neukum + +commit 9f04db234af691007bb785342a06abab5fb34474 upstream. + +This device needs US_FL_NO_REPORT_OPCODES to avoid going +through prolonged error handling on enumeration. + +Signed-off-by: Oliver Neukum +Reported-by: Julian Groß +Cc: stable +Link: https://lore.kernel.org/r/20200429155218.7308-1-oneukum@suse.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/storage/unusual_uas.h | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/usb/storage/unusual_uas.h ++++ b/drivers/usb/storage/unusual_uas.h +@@ -28,6 +28,13 @@ + * and don't forget to CC: the USB development list + */ + ++/* Reported-by: Julian Groß */ ++UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999, ++ "LaCie", ++ "2Big Quadra USB3", ++ USB_SC_DEVICE, USB_PR_DEVICE, NULL, ++ US_FL_NO_REPORT_OPCODES), ++ + /* + * Apricorn USB3 dongle sometimes returns "USBSUSBSUSBS" in response to SCSI + * commands in UAS mode. Observed with the 1.28 firmware; are there others? -- 2.47.3