From: Greg Kroah-Hartman Date: Tue, 12 May 2020 10:42:21 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.19.123~41 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=0d8a3d05da8977e2cdf7dd8fbbc5f4d230f6b1e2;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.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 --- diff --git a/queue-4.9/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch b/queue-4.9/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch new file mode 100644 index 00000000000..2e108809099 --- /dev/null +++ b/queue-4.9/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 +@@ -1100,6 +1100,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.9/revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch b/queue-4.9/revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch new file mode 100644 index 00000000000..12acb62316a --- /dev/null +++ b/queue-4.9/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 +@@ -314,17 +314,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.9/series b/queue-4.9/series index e548731f84c..c7c45c36c24 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -10,3 +10,8 @@ bnxt_en-fix-vlan-acceleration-handling-in-bnxt_fix_features.patch net-mlx5-fix-forced-completion-access-non-initialized-command-entry.patch net-mlx5-fix-command-entry-leak-in-internal-error-state.patch bnxt_en-improve-aer-slot-reset.patch +revert-acpi-video-add-force_native-quirk-for-hp-pavilion-dv6.patch +binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.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.9/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch b/queue-4.9/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch new file mode 100644 index 00000000000..8ffdecbef96 --- /dev/null +++ b/queue-4.9/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 +@@ -7032,6 +7032,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.9/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch b/queue-4.9/usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch new file mode 100644 index 00000000000..5d0268b0fa9 --- /dev/null +++ b/queue-4.9/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 +@@ -1161,8 +1161,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.9/usb-uas-add-quirk-for-lacie-2big-quadra.patch b/queue-4.9/usb-uas-add-quirk-for-lacie-2big-quadra.patch new file mode 100644 index 00000000000..de3de8ed387 --- /dev/null +++ b/queue-4.9/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 +@@ -41,6 +41,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?