--- /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
+@@ -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
--- /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
+@@ -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"),
+- },
+- },
+-
+ { },
+ };
+
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
--- /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
+@@ -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;
+ }
+
--- /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
+@@ -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;
--- /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
+@@ -41,6 +41,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?
projects / thirdparty / kernel / stable-queue.git / commitdiff
