From 7a94a359777bddd6265a2b1646d3fcd808335fbd Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 12 May 2020 12:42:07 +0200 Subject: [PATCH] 4.4-stable patches added patches: binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch enic-do-not-overwrite-error-code.patch ipv6-fix-cleanup-ordering-for-ip6_mr-failure.patch revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch revert-ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch usb-uas-add-quirk-for-lacie-2big-quadra.patch x86-apm-don-t-access-__preempt_count-with-zeroed-fs.patch --- ...f-mmap-when-doing-direct-loader-exec.patch | 105 +++++++++++++ .../enic-do-not-overwrite-error-code.patch | 48 ++++++ ...-cleanup-ordering-for-ip6_mr-failure.patch | 64 ++++++++ ...rce_native-quirk-for-hp-pavilion-dv6.patch | 61 ++++++++ ...if-pkey-value-was-changed-in-index-0.patch | 76 ++++++++++ queue-4.4/series | 9 ++ ...alloc_sync_mappings-for-safe-measure.patch | 62 ++++++++ ...-add-sanity-checking-for-data-length.patch | 35 +++++ ...-uas-add-quirk-for-lacie-2big-quadra.patch | 41 +++++ ...ccess-__preempt_count-with-zeroed-fs.patch | 142 ++++++++++++++++++ 10 files changed, 643 insertions(+) create mode 100644 queue-4.4/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch create mode 100644 queue-4.4/enic-do-not-overwrite-error-code.patch create mode 100644 queue-4.4/ipv6-fix-cleanup-ordering-for-ip6_mr-failure.patch create mode 100644 queue-4.4/revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch create mode 100644 queue-4.4/revert-ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch create mode 100644 queue-4.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch create mode 100644 queue-4.4/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch create mode 100644 queue-4.4/usb-uas-add-quirk-for-lacie-2big-quadra.patch create mode 100644 queue-4.4/x86-apm-don-t-access-__preempt_count-with-zeroed-fs.patch diff --git a/queue-4.4/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch b/queue-4.4/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch new file mode 100644 index 00000000000..2d3c10edf07 --- /dev/null +++ b/queue-4.4/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch @@ -0,0 +1,105 @@ +From bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 Mon Sep 17 00:00:00 2001 +From: Kees Cook +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 + +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 +Reported-by: Ali Saidi +Cc: Ali Saidi +Cc: Guenter Roeck +Cc: Michal Hocko +Cc: Matthew Wilcox +Cc: Thomas Gleixner +Cc: Jann Horn +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.4/enic-do-not-overwrite-error-code.patch b/queue-4.4/enic-do-not-overwrite-error-code.patch new file mode 100644 index 00000000000..d30dc6f40cb --- /dev/null +++ b/queue-4.4/enic-do-not-overwrite-error-code.patch @@ -0,0 +1,48 @@ +From 56f772279a762984f6e9ebbf24a7c829faba5712 Mon Sep 17 00:00:00 2001 +From: Govindarajulu Varadarajan +Date: Mon, 18 Jun 2018 10:01:05 -0700 +Subject: enic: do not overwrite error code + +From: Govindarajulu Varadarajan + +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 +Fixes: e8588e268509 ("enic: enable rq before updating rq descriptors") +Signed-off-by: Govindarajulu Varadarajan +Signed-off-by: David S. Miller +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-4.4/ipv6-fix-cleanup-ordering-for-ip6_mr-failure.patch b/queue-4.4/ipv6-fix-cleanup-ordering-for-ip6_mr-failure.patch new file mode 100644 index 00000000000..62b75737a80 --- /dev/null +++ b/queue-4.4/ipv6-fix-cleanup-ordering-for-ip6_mr-failure.patch @@ -0,0 +1,64 @@ +From afe49de44c27a89e8e9631c44b5ffadf6ace65e2 Mon Sep 17 00:00:00 2001 +From: Sabrina Dubroca +Date: Tue, 28 Aug 2018 13:40:51 +0200 +Subject: ipv6: fix cleanup ordering for ip6_mr failure + +From: Sabrina Dubroca + +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 +Signed-off-by: David S. Miller +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch b/queue-4.4/revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch new file mode 100644 index 00000000000..998b0ee26b3 --- /dev/null +++ b/queue-4.4/revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch @@ -0,0 +1,61 @@ +From fd25ea29093e275195d0ae8b2573021a1c98959f Mon Sep 17 00:00:00 2001 +From: Hans de Goede +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 + +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 +Signed-off-by: Rafael J. Wysocki +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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"), +- }, +- }, +- + { }, + }; + diff --git a/queue-4.4/revert-ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch b/queue-4.4/revert-ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch new file mode 100644 index 00000000000..263a5feb0c1 --- /dev/null +++ b/queue-4.4/revert-ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch @@ -0,0 +1,76 @@ +From 612601d0013f03de9dc134809f242ba6da9ca252 Mon Sep 17 00:00:00 2001 +From: Alex Estrin +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 + +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 +Reviewed-by: Dennis Dalessandro +Signed-off-by: Alex Estrin +Signed-off-by: Dennis Dalessandro +Reviewed-by: Feras Daoud +Signed-off-by: Doug Ledford +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.4/series b/queue-4.4/series index 398a9123587..a5aae02ead2 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -4,3 +4,12 @@ dp83640-reverse-arguments-to-list_add_tail.patch 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 diff --git a/queue-4.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch b/queue-4.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch new file mode 100644 index 00000000000..6856bcf4f48 --- /dev/null +++ b/queue-4.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 +@@ -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; + } + diff --git a/queue-4.4/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch b/queue-4.4/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch new file mode 100644 index 00000000000..620e73fab10 --- /dev/null +++ b/queue-4.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 +@@ -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; diff --git a/queue-4.4/usb-uas-add-quirk-for-lacie-2big-quadra.patch b/queue-4.4/usb-uas-add-quirk-for-lacie-2big-quadra.patch new file mode 100644 index 00000000000..f4970f143fc --- /dev/null +++ b/queue-4.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 +@@ -40,6 +40,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? diff --git a/queue-4.4/x86-apm-don-t-access-__preempt_count-with-zeroed-fs.patch b/queue-4.4/x86-apm-don-t-access-__preempt_count-with-zeroed-fs.patch new file mode 100644 index 00000000000..d92b5dd3ad6 --- /dev/null +++ b/queue-4.4/x86-apm-don-t-access-__preempt_count-with-zeroed-fs.patch @@ -0,0 +1,142 @@ +From 6f6060a5c9cc76fdbc22748264e6aa3779ec2427 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +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ä + +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ä +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Cc: David Woodhouse +Cc: "H. Peter Anvin" +Cc: x86@kernel.org +Cc: David Woodhouse +Cc: "H. Peter Anvin" +Link: https://lkml.kernel.org/r/20180709133534.5963-1-ville.syrjala@linux.intel.com +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +- + #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 + #include + #include ++#include + + #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(); -- 2.47.3