--- /dev/null
+From bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Tue, 14 May 2019 15:43:57 -0700
+Subject: binfmt_elf: move brk out of mmap when doing direct loader exec
+
+From: Kees Cook <keescook@chromium.org>
+
+commit bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 upstream.
+
+Commmit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"),
+made changes in the rare case when the ELF loader was directly invoked
+(e.g to set a non-inheritable LD_LIBRARY_PATH, testing new versions of
+the loader), by moving into the mmap region to avoid both ET_EXEC and
+PIE binaries. This had the effect of also moving the brk region into
+mmap, which could lead to the stack and brk being arbitrarily close to
+each other. An unlucky process wouldn't get its requested stack size
+and stack allocations could end up scribbling on the heap.
+
+This is illustrated here. In the case of using the loader directly, brk
+(so helpfully identified as "[heap]") is allocated with the _loader_ not
+the binary. For example, with ASLR entirely disabled, you can see this
+more clearly:
+
+$ /bin/cat /proc/self/maps
+555555554000-55555555c000 r-xp 00000000 ... /bin/cat
+55555575b000-55555575c000 r--p 00007000 ... /bin/cat
+55555575c000-55555575d000 rw-p 00008000 ... /bin/cat
+55555575d000-55555577e000 rw-p 00000000 ... [heap]
+...
+7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
+7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
+7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7ffe000-7ffff7fff000 rw-p 00000000 ...
+7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
+
+$ /lib/x86_64-linux-gnu/ld-2.27.so /bin/cat /proc/self/maps
+...
+7ffff7bcc000-7ffff7bd4000 r-xp 00000000 ... /bin/cat
+7ffff7bd4000-7ffff7dd3000 ---p 00008000 ... /bin/cat
+7ffff7dd3000-7ffff7dd4000 r--p 00007000 ... /bin/cat
+7ffff7dd4000-7ffff7dd5000 rw-p 00008000 ... /bin/cat
+7ffff7dd5000-7ffff7dfc000 r-xp 00000000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7fb2000-7ffff7fd6000 rw-p 00000000 ...
+7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
+7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
+7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7ffe000-7ffff8020000 rw-p 00000000 ... [heap]
+7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
+
+The solution is to move brk out of mmap and into ELF_ET_DYN_BASE since
+nothing is there in the direct loader case (and ET_EXEC is still far
+away at 0x400000). Anything that ran before should still work (i.e.
+the ultimately-launched binary already had the brk very far from its
+text, so this should be no different from a COMPAT_BRK standpoint). The
+only risk I see here is that if someone started to suddenly depend on
+the entire memory space lower than the mmap region being available when
+launching binaries via a direct loader execs which seems highly
+unlikely, I'd hope: this would mean a binary would _not_ work when
+exec()ed normally.
+
+(Note that this is only done under CONFIG_ARCH_HAS_ELF_RANDOMIZATION
+when randomization is turned on.)
+
+Link: http://lkml.kernel.org/r/20190422225727.GA21011@beast
+Link: https://lkml.kernel.org/r/CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=Omfhx_p0nCKPSjA@mail.gmail.com
+Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Reported-by: Ali Saidi <alisaidi@amazon.com>
+Cc: Ali Saidi <alisaidi@amazon.com>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Jann Horn <jannh@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/binfmt_elf.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/binfmt_elf.c
++++ b/fs/binfmt_elf.c
+@@ -1097,6 +1097,17 @@ static int load_elf_binary(struct linux_
+ current->mm->start_stack = bprm->p;
+
+ if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) {
++ /*
++ * For architectures with ELF randomization, when executing
++ * a loader directly (i.e. no interpreter listed in ELF
++ * headers), move the brk area out of the mmap region
++ * (since it grows up, and may collide early with the stack
++ * growing down), and into the unused ELF_ET_DYN_BASE region.
++ */
++ if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) && !interpreter)
++ current->mm->brk = current->mm->start_brk =
++ ELF_ET_DYN_BASE;
++
+ current->mm->brk = current->mm->start_brk =
+ arch_randomize_brk(current->mm);
+ #ifdef compat_brk_randomized
--- /dev/null
+From 56f772279a762984f6e9ebbf24a7c829faba5712 Mon Sep 17 00:00:00 2001
+From: Govindarajulu Varadarajan <gvaradar@cisco.com>
+Date: Mon, 18 Jun 2018 10:01:05 -0700
+Subject: enic: do not overwrite error code
+
+From: Govindarajulu Varadarajan <gvaradar@cisco.com>
+
+commit 56f772279a762984f6e9ebbf24a7c829faba5712 upstream.
+
+In failure path, we overwrite err to what vnic_rq_disable() returns. In
+case it returns 0, enic_open() returns success in case of error.
+
+Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Fixes: e8588e268509 ("enic: enable rq before updating rq descriptors")
+Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/cisco/enic/enic_main.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/ethernet/cisco/enic/enic_main.c
++++ b/drivers/net/ethernet/cisco/enic/enic_main.c
+@@ -1708,7 +1708,7 @@ static int enic_open(struct net_device *
+ {
+ struct enic *enic = netdev_priv(netdev);
+ unsigned int i;
+- int err;
++ int err, ret;
+
+ err = enic_request_intr(enic);
+ if (err) {
+@@ -1766,10 +1766,9 @@ static int enic_open(struct net_device *
+
+ err_out_free_rq:
+ for (i = 0; i < enic->rq_count; i++) {
+- err = vnic_rq_disable(&enic->rq[i]);
+- if (err)
+- return err;
+- vnic_rq_clean(&enic->rq[i], enic_free_rq_buf);
++ ret = vnic_rq_disable(&enic->rq[i]);
++ if (!ret)
++ vnic_rq_clean(&enic->rq[i], enic_free_rq_buf);
+ }
+ enic_dev_notify_unset(enic);
+ err_out_free_intr:
--- /dev/null
+From afe49de44c27a89e8e9631c44b5ffadf6ace65e2 Mon Sep 17 00:00:00 2001
+From: Sabrina Dubroca <sd@queasysnail.net>
+Date: Tue, 28 Aug 2018 13:40:51 +0200
+Subject: ipv6: fix cleanup ordering for ip6_mr failure
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+commit afe49de44c27a89e8e9631c44b5ffadf6ace65e2 upstream.
+
+Commit 15e668070a64 ("ipv6: reorder icmpv6_init() and ip6_mr_init()")
+moved the cleanup label for ipmr_fail, but should have changed the
+contents of the cleanup labels as well. Now we can end up cleaning up
+icmpv6 even though it hasn't been initialized (jump to icmp_fail or
+ipmr_fail).
+
+Simply undo things in the reverse order of their initialization.
+
+Example of panic (triggered by faking a failure of icmpv6_init):
+
+ kasan: GPF could be caused by NULL-ptr deref or user memory access
+ general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
+ [...]
+ RIP: 0010:__list_del_entry_valid+0x79/0x160
+ [...]
+ Call Trace:
+ ? lock_release+0x8a0/0x8a0
+ unregister_pernet_operations+0xd4/0x560
+ ? ops_free_list+0x480/0x480
+ ? down_write+0x91/0x130
+ ? unregister_pernet_subsys+0x15/0x30
+ ? down_read+0x1b0/0x1b0
+ ? up_read+0x110/0x110
+ ? kmem_cache_create_usercopy+0x1b4/0x240
+ unregister_pernet_subsys+0x1d/0x30
+ icmpv6_cleanup+0x1d/0x30
+ inet6_init+0x1b5/0x23f
+
+Fixes: 15e668070a64 ("ipv6: reorder icmpv6_init() and ip6_mr_init()")
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/ipv6/af_inet6.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/net/ipv6/af_inet6.c
++++ b/net/ipv6/af_inet6.c
+@@ -1029,11 +1029,11 @@ netfilter_fail:
+ igmp_fail:
+ ndisc_cleanup();
+ ndisc_fail:
+- ip6_mr_cleanup();
++ icmpv6_cleanup();
+ icmp_fail:
+- unregister_pernet_subsys(&inet6_net_ops);
++ ip6_mr_cleanup();
+ ipmr_fail:
+- icmpv6_cleanup();
++ unregister_pernet_subsys(&inet6_net_ops);
+ register_pernet_fail:
+ sock_unregister(PF_INET6);
+ rtnl_unregister_all(PF_INET6);
--- /dev/null
+From fd25ea29093e275195d0ae8b2573021a1c98959f Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Sun, 22 Jan 2017 13:24:05 +0100
+Subject: Revert "ACPI / video: Add force_native quirk for HP Pavilion dv6"
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit fd25ea29093e275195d0ae8b2573021a1c98959f upstream.
+
+Revert commit 6276e53fa8c0 (ACPI / video: Add force_native quirk for
+HP Pavilion dv6).
+
+In the commit message for the quirk this revert removes I wrote:
+
+"Note that there are quite a few HP Pavilion dv6 variants, some
+woth ATI and some with NVIDIA hybrid gfx, both seem to need this
+quirk to have working backlight control. There are also some versions
+with only Intel integrated gfx, these may not need this quirk, but it
+should not hurt there."
+
+Unfortunately that seems wrong, I've already received 2 reports of
+this commit causing regressions on some dv6 variants (at least one
+of which actually has a nvidia GPU). So it seems that HP has made a
+mess here by using the same model-name both in marketing and in the
+DMI data for many different variants. Some of which need
+acpi_backlight=native for functional backlight control (as the
+quirk this commit reverts was doing), where as others are broken by
+it. So lets get back to the old sitation so as to avoid regressing
+on models which used to work without any kernel cmdline arguments
+before.
+
+Fixes: 6276e53fa8c0 (ACPI / video: Add force_native quirk for HP Pavilion dv6)
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/video_detect.c | 11 -----------
+ 1 file changed, 11 deletions(-)
+
+--- a/drivers/acpi/video_detect.c
++++ b/drivers/acpi/video_detect.c
+@@ -289,17 +289,6 @@ static const struct dmi_system_id video_
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L702X"),
+ },
+ },
+- {
+- /* https://bugzilla.redhat.com/show_bug.cgi?id=1204476 */
+- /* https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1416940 */
+- .callback = video_detect_force_native,
+- .ident = "HP Pavilion dv6",
+- .matches = {
+- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+- DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dv6 Notebook PC"),
+- },
+- },
+-
+ { },
+ };
+
--- /dev/null
+From 612601d0013f03de9dc134809f242ba6da9ca252 Mon Sep 17 00:00:00 2001
+From: Alex Estrin <alex.estrin@intel.com>
+Date: Tue, 26 Sep 2017 06:06:22 -0700
+Subject: Revert "IB/ipoib: Update broadcast object if PKey value was changed in index 0"
+
+From: Alex Estrin <alex.estrin@intel.com>
+
+commit 612601d0013f03de9dc134809f242ba6da9ca252 upstream.
+
+commit 9a9b8112699d will cause core to fail UD QP from being destroyed
+on ipoib unload, therefore cause resources leakage.
+On pkey change event above patch modifies mgid before calling underlying
+driver to detach it from QP. Drivers' detach_mcast() will fail to find
+modified mgid it was never given to attach in a first place.
+Core qp->usecnt will never go down, so ib_destroy_qp() will fail.
+
+IPoIB driver actually does take care of new broadcast mgid based on new
+pkey by destroying an old mcast object in ipoib_mcast_dev_flush())
+....
+ if (priv->broadcast) {
+ rb_erase(&priv->broadcast->rb_node, &priv->multicast_tree);
+ list_add_tail(&priv->broadcast->list, &remove_list);
+ priv->broadcast = NULL;
+ }
+...
+
+then in restarted ipoib_macst_join_task() creating a new broadcast mcast
+object, sending join request and on completion tells the driver to attach
+to reinitialized QP:
+...
+if (!priv->broadcast) {
+...
+ broadcast = ipoib_mcast_alloc(dev, 0);
+...
+ memcpy(broadcast->mcmember.mgid.raw, priv->dev->broadcast + 4,
+ sizeof (union ib_gid));
+ priv->broadcast = broadcast;
+...
+
+Fixes: 9a9b8112699d ("IB/ipoib: Update broadcast object if PKey value was changed in index 0")
+Cc: stable@vger.kernel.org
+Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Alex Estrin <alex.estrin@intel.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Reviewed-by: Feras Daoud <ferasda@mellanox.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 -------------
+ 1 file changed, 13 deletions(-)
+
+--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
++++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+@@ -945,19 +945,6 @@ static inline int update_parent_pkey(str
+ */
+ priv->dev->broadcast[8] = priv->pkey >> 8;
+ priv->dev->broadcast[9] = priv->pkey & 0xff;
+-
+- /*
+- * Update the broadcast address in the priv->broadcast object,
+- * in case it already exists, otherwise no one will do that.
+- */
+- if (priv->broadcast) {
+- spin_lock_irq(&priv->lock);
+- memcpy(priv->broadcast->mcmember.mgid.raw,
+- priv->dev->broadcast + 4,
+- sizeof(union ib_gid));
+- spin_unlock_irq(&priv->lock);
+- }
+-
+ return 0;
+ }
+
net-mlx4_core-fix-use-of-enospc-around-mlx4_counter_alloc.patch
sch_sfq-validate-silly-quantum-values.patch
sch_choke-avoid-potential-panic-in-choke_reset.patch
+revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch
+enic-do-not-overwrite-error-code.patch
+ipv6-fix-cleanup-ordering-for-ip6_mr-failure.patch
+binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch
+x86-apm-don-t-access-__preempt_count-with-zeroed-fs.patch
+revert-ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch
+usb-uas-add-quirk-for-lacie-2big-quadra.patch
+usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch
+tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch
--- /dev/null
+From 11f5efc3ab66284f7aaacc926e9351d658e2577b Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Wed, 6 May 2020 10:36:18 -0400
+Subject: tracing: Add a vmalloc_sync_mappings() for safe measure
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+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)" <tz.stoyanov@gmail.com>
+Suggested-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6621,6 +6621,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;
+ }
+
--- /dev/null
+From e9b3c610a05c1cdf8e959a6d89c38807ff758ee6 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Wed, 15 Apr 2020 16:03:04 +0200
+Subject: USB: serial: garmin_gps: add sanity checking for data length
+
+From: Oliver Neukum <oneukum@suse.com>
+
+commit e9b3c610a05c1cdf8e959a6d89c38807ff758ee6 upstream.
+
+We must not process packets shorter than a packet ID
+
+Signed-off-by: Oliver Neukum <oneukum@suse.com>
+Reported-and-tested-by: syzbot+d29e9263e13ce0b9f4fd@syzkaller.appspotmail.com
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1162,8 +1162,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;
--- /dev/null
+From 9f04db234af691007bb785342a06abab5fb34474 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+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 <oneukum@suse.com>
+
+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 <oneukum@suse.com>
+Reported-by: Julian Groß <julian.g@posteo.de>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200429155218.7308-1-oneukum@suse.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -40,6 +40,13 @@
+ * and don't forget to CC: the USB development list <linux-usb@vger.kernel.org>
+ */
+
++/* Reported-by: Julian Groß <julian.g@posteo.de> */
++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?
--- /dev/null
+From 6f6060a5c9cc76fdbc22748264e6aa3779ec2427 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Mon, 9 Jul 2018 16:35:34 +0300
+Subject: x86/apm: Don't access __preempt_count with zeroed fs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit 6f6060a5c9cc76fdbc22748264e6aa3779ec2427 upstream.
+
+APM_DO_POP_SEGS does not restore fs/gs which were zeroed by
+APM_DO_ZERO_SEGS. Trying to access __preempt_count with
+zeroed fs doesn't really work.
+
+Move the ibrs call outside the APM_DO_SAVE_SEGS/APM_DO_RESTORE_SEGS
+invocations so that fs is actually restored before calling
+preempt_enable().
+
+Fixes the following sort of oopses:
+[ 0.313581] general protection fault: 0000 [#1] PREEMPT SMP
+[ 0.313803] Modules linked in:
+[ 0.314040] CPU: 0 PID: 268 Comm: kapmd Not tainted 4.16.0-rc1-triton-bisect-00090-gdd84441a7971 #19
+[ 0.316161] EIP: __apm_bios_call_simple+0xc8/0x170
+[ 0.316161] EFLAGS: 00210016 CPU: 0
+[ 0.316161] EAX: 00000102 EBX: 00000000 ECX: 00000102 EDX: 00000000
+[ 0.316161] ESI: 0000530e EDI: dea95f64 EBP: dea95f18 ESP: dea95ef0
+[ 0.316161] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
+[ 0.316161] CR0: 80050033 CR2: 00000000 CR3: 015d3000 CR4: 000006d0
+[ 0.316161] Call Trace:
+[ 0.316161] ? cpumask_weight.constprop.15+0x20/0x20
+[ 0.316161] on_cpu0+0x44/0x70
+[ 0.316161] apm+0x54e/0x720
+[ 0.316161] ? __switch_to_asm+0x26/0x40
+[ 0.316161] ? __schedule+0x17d/0x590
+[ 0.316161] kthread+0xc0/0xf0
+[ 0.316161] ? proc_apm_show+0x150/0x150
+[ 0.316161] ? kthread_create_worker_on_cpu+0x20/0x20
+[ 0.316161] ret_from_fork+0x2e/0x38
+[ 0.316161] Code: da 8e c2 8e e2 8e ea 57 55 2e ff 1d e0 bb 5d b1 0f 92 c3 5d 5f 07 1f 89 47 0c 90 8d b4 26 00 00 00 00 90 8d b4 26 00 00 00 00 90 <64> ff 0d 84 16 5c b1 74 7f 8b 45 dc 8e e0 8b 45 d8 8e e8 8b 45
+[ 0.316161] EIP: __apm_bios_call_simple+0xc8/0x170 SS:ESP: 0068:dea95ef0
+[ 0.316161] ---[ end trace 656253db2deaa12c ]---
+
+Fixes: dd84441a7971 ("x86/speculation: Use IBRS if available before calling into firmware")
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Cc: David Woodhouse <dwmw@amazon.co.uk>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: x86@kernel.org
+Cc: David Woodhouse <dwmw@amazon.co.uk>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Link: https://lkml.kernel.org/r/20180709133534.5963-1-ville.syrjala@linux.intel.com
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/apm.h | 6 ------
+ arch/x86/kernel/apm_32.c | 5 +++++
+ 2 files changed, 5 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/include/asm/apm.h
++++ b/arch/x86/include/asm/apm.h
+@@ -6,8 +6,6 @@
+ #ifndef _ASM_X86_MACH_DEFAULT_APM_H
+ #define _ASM_X86_MACH_DEFAULT_APM_H
+
+-#include <asm/nospec-branch.h>
+-
+ #ifdef APM_ZERO_SEGS
+ # define APM_DO_ZERO_SEGS \
+ "pushl %%ds\n\t" \
+@@ -33,7 +31,6 @@ static inline void apm_bios_call_asm(u32
+ * N.B. We do NOT need a cld after the BIOS call
+ * because we always save and restore the flags.
+ */
+- firmware_restrict_branch_speculation_start();
+ __asm__ __volatile__(APM_DO_ZERO_SEGS
+ "pushl %%edi\n\t"
+ "pushl %%ebp\n\t"
+@@ -46,7 +43,6 @@ static inline void apm_bios_call_asm(u32
+ "=S" (*esi)
+ : "a" (func), "b" (ebx_in), "c" (ecx_in)
+ : "memory", "cc");
+- firmware_restrict_branch_speculation_end();
+ }
+
+ static inline u8 apm_bios_call_simple_asm(u32 func, u32 ebx_in,
+@@ -59,7 +55,6 @@ static inline u8 apm_bios_call_simple_as
+ * N.B. We do NOT need a cld after the BIOS call
+ * because we always save and restore the flags.
+ */
+- firmware_restrict_branch_speculation_start();
+ __asm__ __volatile__(APM_DO_ZERO_SEGS
+ "pushl %%edi\n\t"
+ "pushl %%ebp\n\t"
+@@ -72,7 +67,6 @@ static inline u8 apm_bios_call_simple_as
+ "=S" (si)
+ : "a" (func), "b" (ebx_in), "c" (ecx_in)
+ : "memory", "cc");
+- firmware_restrict_branch_speculation_end();
+ return error;
+ }
+
+--- a/arch/x86/kernel/apm_32.c
++++ b/arch/x86/kernel/apm_32.c
+@@ -239,6 +239,7 @@
+ #include <asm/olpc.h>
+ #include <asm/paravirt.h>
+ #include <asm/reboot.h>
++#include <asm/nospec-branch.h>
+
+ #if defined(CONFIG_APM_DISPLAY_BLANK) && defined(CONFIG_VT)
+ extern int (*console_blank_hook)(int);
+@@ -613,11 +614,13 @@ static long __apm_bios_call(void *_call)
+ gdt[0x40 / 8] = bad_bios_desc;
+
+ apm_irq_save(flags);
++ firmware_restrict_branch_speculation_start();
+ APM_DO_SAVE_SEGS;
+ apm_bios_call_asm(call->func, call->ebx, call->ecx,
+ &call->eax, &call->ebx, &call->ecx, &call->edx,
+ &call->esi);
+ APM_DO_RESTORE_SEGS;
++ firmware_restrict_branch_speculation_end();
+ apm_irq_restore(flags);
+ gdt[0x40 / 8] = save_desc_40;
+ put_cpu();
+@@ -689,10 +692,12 @@ static long __apm_bios_call_simple(void
+ gdt[0x40 / 8] = bad_bios_desc;
+
+ apm_irq_save(flags);
++ firmware_restrict_branch_speculation_start();
+ APM_DO_SAVE_SEGS;
+ error = apm_bios_call_simple_asm(call->func, call->ebx, call->ecx,
+ &call->eax);
+ APM_DO_RESTORE_SEGS;
++ firmware_restrict_branch_speculation_end();
+ apm_irq_restore(flags);
+ gdt[0x40 / 8] = save_desc_40;
+ put_cpu();
projects / thirdparty / kernel / stable-queue.git / commitdiff
