From: Greg Kroah-Hartman Date: Wed, 22 Apr 2020 08:48:06 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.19.118~8 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f4ea4fd7f169a041468cde265c7d06212337d136;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: fbdev-potential-information-leak-in-do_fb_ioctl.patch locktorture-print-ratio-of-acquisitions-not-failures.patch mtd-lpddr-fix-a-double-free-in-probe.patch mtd-phram-fix-a-double-free-issue-in-error-path.patch tty-evh_bytechan-fix-out-of-bounds-accesses.patch x86-cpu-add-native-cpuid-variants-returning-a-single-datum.patch x86-microcode-intel-replace-sync_core-with-native_cpuid_reg-eax.patch x86-vdso-fix-lsl-operand-order.patch --- diff --git a/queue-4.9/fbdev-potential-information-leak-in-do_fb_ioctl.patch b/queue-4.9/fbdev-potential-information-leak-in-do_fb_ioctl.patch new file mode 100644 index 00000000000..b918ea6fd74 --- /dev/null +++ b/queue-4.9/fbdev-potential-information-leak-in-do_fb_ioctl.patch @@ -0,0 +1,46 @@ +From d3d19d6fc5736a798b118971935ce274f7deaa82 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Mon, 13 Jan 2020 14:08:14 +0300 +Subject: fbdev: potential information leak in do_fb_ioctl() + +From: Dan Carpenter + +commit d3d19d6fc5736a798b118971935ce274f7deaa82 upstream. + +The "fix" struct has a 2 byte hole after ->ywrapstep and the +"fix = info->fix;" assignment doesn't necessarily clear it. It depends +on the compiler. The solution is just to replace the assignment with an +memcpy(). + +Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex held") +Signed-off-by: Dan Carpenter +Cc: Andrew Morton +Cc: Arnd Bergmann +Cc: "Eric W. Biederman" +Cc: Andrea Righi +Cc: Daniel Vetter +Cc: Sam Ravnborg +Cc: Maarten Lankhorst +Cc: Daniel Thompson +Cc: Peter Rosin +Cc: Jani Nikula +Cc: Gerd Hoffmann +Signed-off-by: Bartlomiej Zolnierkiewicz +Link: https://patchwork.freedesktop.org/patch/msgid/20200113100132.ixpaymordi24n3av@kili.mountain +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/video/fbdev/core/fbmem.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/video/fbdev/core/fbmem.c ++++ b/drivers/video/fbdev/core/fbmem.c +@@ -1132,7 +1132,7 @@ static long do_fb_ioctl(struct fb_info * + case FBIOGET_FSCREENINFO: + if (!lock_fb_info(info)) + return -ENODEV; +- fix = info->fix; ++ memcpy(&fix, &info->fix, sizeof(fix)); + unlock_fb_info(info); + + ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0; diff --git a/queue-4.9/locktorture-print-ratio-of-acquisitions-not-failures.patch b/queue-4.9/locktorture-print-ratio-of-acquisitions-not-failures.patch new file mode 100644 index 00000000000..309536c0a04 --- /dev/null +++ b/queue-4.9/locktorture-print-ratio-of-acquisitions-not-failures.patch @@ -0,0 +1,50 @@ +From 80c503e0e68fbe271680ab48f0fe29bc034b01b7 Mon Sep 17 00:00:00 2001 +From: "Paul E. McKenney" +Date: Thu, 23 Jan 2020 09:19:01 -0800 +Subject: locktorture: Print ratio of acquisitions, not failures + +From: Paul E. McKenney + +commit 80c503e0e68fbe271680ab48f0fe29bc034b01b7 upstream. + +The __torture_print_stats() function in locktorture.c carefully +initializes local variable "min" to statp[0].n_lock_acquired, but +then compares it to statp[i].n_lock_fail. Given that the .n_lock_fail +field should normally be zero, and given the initialization, it seems +reasonable to display the maximum and minimum number acquisitions +instead of miscomputing the maximum and minimum number of failures. +This commit therefore switches from failures to acquisitions. + +And this turns out to be not only a day-zero bug, but entirely my +own fault. I hate it when that happens! + +Fixes: 0af3fe1efa53 ("locktorture: Add a lock-torture kernel module") +Reported-by: Will Deacon +Signed-off-by: Paul E. McKenney +Acked-by: Will Deacon +Cc: Davidlohr Bueso +Cc: Josh Triplett +Cc: Peter Zijlstra +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/locking/locktorture.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/kernel/locking/locktorture.c ++++ b/kernel/locking/locktorture.c +@@ -649,10 +649,10 @@ static void __torture_print_stats(char * + if (statp[i].n_lock_fail) + fail = true; + sum += statp[i].n_lock_acquired; +- if (max < statp[i].n_lock_fail) +- max = statp[i].n_lock_fail; +- if (min > statp[i].n_lock_fail) +- min = statp[i].n_lock_fail; ++ if (max < statp[i].n_lock_acquired) ++ max = statp[i].n_lock_acquired; ++ if (min > statp[i].n_lock_acquired) ++ min = statp[i].n_lock_acquired; + } + page += sprintf(page, + "%s: Total: %lld Max/Min: %ld/%ld %s Fail: %d %s\n", diff --git a/queue-4.9/mtd-lpddr-fix-a-double-free-in-probe.patch b/queue-4.9/mtd-lpddr-fix-a-double-free-in-probe.patch new file mode 100644 index 00000000000..3d59f0c5725 --- /dev/null +++ b/queue-4.9/mtd-lpddr-fix-a-double-free-in-probe.patch @@ -0,0 +1,33 @@ +From 4da0ea71ea934af18db4c63396ba2af1a679ef02 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Fri, 28 Feb 2020 12:25:54 +0300 +Subject: mtd: lpddr: Fix a double free in probe() + +From: Dan Carpenter + +commit 4da0ea71ea934af18db4c63396ba2af1a679ef02 upstream. + +This function is only called from lpddr_probe(). We free "lpddr" both +here and in the caller, so it's a double free. The best place to free +"lpddr" is in lpddr_probe() so let's delete this one. + +Fixes: 8dc004395d5e ("[MTD] LPDDR qinfo probing.") +Signed-off-by: Dan Carpenter +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20200228092554.o57igp3nqhyvf66t@kili.mountain +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/lpddr/lpddr_cmds.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/mtd/lpddr/lpddr_cmds.c ++++ b/drivers/mtd/lpddr/lpddr_cmds.c +@@ -81,7 +81,6 @@ struct mtd_info *lpddr_cmdset(struct map + shared = kmalloc(sizeof(struct flchip_shared) * lpddr->numchips, + GFP_KERNEL); + if (!shared) { +- kfree(lpddr); + kfree(mtd); + return NULL; + } diff --git a/queue-4.9/mtd-phram-fix-a-double-free-issue-in-error-path.patch b/queue-4.9/mtd-phram-fix-a-double-free-issue-in-error-path.patch new file mode 100644 index 00000000000..9dd9fb629a8 --- /dev/null +++ b/queue-4.9/mtd-phram-fix-a-double-free-issue-in-error-path.patch @@ -0,0 +1,64 @@ +From 49c64df880570034308e4a9a49c4bc95cf8cdb33 Mon Sep 17 00:00:00 2001 +From: Wen Yang +Date: Wed, 18 Mar 2020 23:31:56 +0800 +Subject: mtd: phram: fix a double free issue in error path + +From: Wen Yang + +commit 49c64df880570034308e4a9a49c4bc95cf8cdb33 upstream. + +The variable 'name' is released multiple times in the error path, +which may cause double free issues. +This problem is avoided by adding a goto label to release the memory +uniformly. And this change also makes the code a bit more cleaner. + +Fixes: 4f678a58d335 ("mtd: fix memory leaks in phram_setup") +Signed-off-by: Wen Yang +Cc: Joern Engel +Cc: Miquel Raynal +Cc: Richard Weinberger +Cc: Vignesh Raghavendra +Cc: linux-mtd@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20200318153156.25612-1-wenyang@linux.alibaba.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/devices/phram.c | 15 +++++++++------ + 1 file changed, 9 insertions(+), 6 deletions(-) + +--- a/drivers/mtd/devices/phram.c ++++ b/drivers/mtd/devices/phram.c +@@ -247,22 +247,25 @@ static int phram_setup(const char *val) + + ret = parse_num64(&start, token[1]); + if (ret) { +- kfree(name); + parse_err("illegal start address\n"); ++ goto error; + } + + ret = parse_num64(&len, token[2]); + if (ret) { +- kfree(name); + parse_err("illegal device length\n"); ++ goto error; + } + + ret = register_device(name, start, len); +- if (!ret) +- pr_info("%s device: %#llx at %#llx\n", name, len, start); +- else +- kfree(name); ++ if (ret) ++ goto error; + ++ pr_info("%s device: %#llx at %#llx\n", name, len, start); ++ return 0; ++ ++error: ++ kfree(name); + return ret; + } + diff --git a/queue-4.9/series b/queue-4.9/series index e95b5b174be..0cfbb536d5b 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -115,3 +115,11 @@ ext2-fix-empty-body-warnings-when-wextra-is-used.patch ext2-fix-debug-reference-to-ext2_xattr_cache.patch libnvdimm-out-of-bounds-read-in-__nd_ioctl.patch iommu-amd-fix-the-configuration-of-gcr3-table-root-p.patch +fbdev-potential-information-leak-in-do_fb_ioctl.patch +tty-evh_bytechan-fix-out-of-bounds-accesses.patch +locktorture-print-ratio-of-acquisitions-not-failures.patch +mtd-lpddr-fix-a-double-free-in-probe.patch +mtd-phram-fix-a-double-free-issue-in-error-path.patch +x86-cpu-add-native-cpuid-variants-returning-a-single-datum.patch +x86-microcode-intel-replace-sync_core-with-native_cpuid_reg-eax.patch +x86-vdso-fix-lsl-operand-order.patch diff --git a/queue-4.9/tty-evh_bytechan-fix-out-of-bounds-accesses.patch b/queue-4.9/tty-evh_bytechan-fix-out-of-bounds-accesses.patch new file mode 100644 index 00000000000..da45d301b5a --- /dev/null +++ b/queue-4.9/tty-evh_bytechan-fix-out-of-bounds-accesses.patch @@ -0,0 +1,111 @@ +From 3670664b5da555a2a481449b3baafff113b0ac35 Mon Sep 17 00:00:00 2001 +From: Stephen Rothwell +Date: Thu, 9 Jan 2020 18:39:12 +1100 +Subject: tty: evh_bytechan: Fix out of bounds accesses +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Stephen Rothwell + +commit 3670664b5da555a2a481449b3baafff113b0ac35 upstream. + +ev_byte_channel_send() assumes that its third argument is a 16 byte +array. Some places where it is called it may not be (or we can't +easily tell if it is). Newer compilers have started producing warnings +about this, so make sure we actually pass a 16 byte array. + +There may be more elegant solutions to this, but the driver is quite +old and hasn't been updated in many years. + +The warnings (from a powerpc allyesconfig build) are: + + In file included from include/linux/byteorder/big_endian.h:5, + from arch/powerpc/include/uapi/asm/byteorder.h:14, + from include/asm-generic/bitops/le.h:6, + from arch/powerpc/include/asm/bitops.h:250, + from include/linux/bitops.h:29, + from include/linux/kernel.h:12, + from include/asm-generic/bug.h:19, + from arch/powerpc/include/asm/bug.h:109, + from include/linux/bug.h:5, + from include/linux/mmdebug.h:5, + from include/linux/gfp.h:5, + from include/linux/slab.h:15, + from drivers/tty/ehv_bytechan.c:24: + drivers/tty/ehv_bytechan.c: In function ‘ehv_bc_udbg_putc’: + arch/powerpc/include/asm/epapr_hcalls.h:298:20: warning: array subscript 1 is outside array bounds of ‘const char[1]’ [-Warray-bounds] + 298 | r6 = be32_to_cpu(p[1]); + include/uapi/linux/byteorder/big_endian.h:40:51: note: in definition of macro ‘__be32_to_cpu’ + 40 | #define __be32_to_cpu(x) ((__force __u32)(__be32)(x)) + | ^ + arch/powerpc/include/asm/epapr_hcalls.h:298:7: note: in expansion of macro ‘be32_to_cpu’ + 298 | r6 = be32_to_cpu(p[1]); + | ^~~~~~~~~~~ + drivers/tty/ehv_bytechan.c:166:13: note: while referencing ‘data’ + 166 | static void ehv_bc_udbg_putc(char c) + | ^~~~~~~~~~~~~~~~ + +Fixes: dcd83aaff1c8 ("tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver") +Signed-off-by: Stephen Rothwell +Tested-by: Laurentiu Tudor +[mpe: Trim warnings from change log] +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20200109183912.5fcb52aa@canb.auug.org.au +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/ehv_bytechan.c | 21 ++++++++++++++++++--- + 1 file changed, 18 insertions(+), 3 deletions(-) + +--- a/drivers/tty/ehv_bytechan.c ++++ b/drivers/tty/ehv_bytechan.c +@@ -139,6 +139,21 @@ static int find_console_handle(void) + return 1; + } + ++static unsigned int local_ev_byte_channel_send(unsigned int handle, ++ unsigned int *count, ++ const char *p) ++{ ++ char buffer[EV_BYTE_CHANNEL_MAX_BYTES]; ++ unsigned int c = *count; ++ ++ if (c < sizeof(buffer)) { ++ memcpy(buffer, p, c); ++ memset(&buffer[c], 0, sizeof(buffer) - c); ++ p = buffer; ++ } ++ return ev_byte_channel_send(handle, count, p); ++} ++ + /*************************** EARLY CONSOLE DRIVER ***************************/ + + #ifdef CONFIG_PPC_EARLY_DEBUG_EHV_BC +@@ -157,7 +172,7 @@ static void byte_channel_spin_send(const + + do { + count = 1; +- ret = ev_byte_channel_send(CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE, ++ ret = local_ev_byte_channel_send(CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE, + &count, &data); + } while (ret == EV_EAGAIN); + } +@@ -224,7 +239,7 @@ static int ehv_bc_console_byte_channel_s + while (count) { + len = min_t(unsigned int, count, EV_BYTE_CHANNEL_MAX_BYTES); + do { +- ret = ev_byte_channel_send(handle, &len, s); ++ ret = local_ev_byte_channel_send(handle, &len, s); + } while (ret == EV_EAGAIN); + count -= len; + s += len; +@@ -404,7 +419,7 @@ static void ehv_bc_tx_dequeue(struct ehv + CIRC_CNT_TO_END(bc->head, bc->tail, BUF_SIZE), + EV_BYTE_CHANNEL_MAX_BYTES); + +- ret = ev_byte_channel_send(bc->handle, &len, bc->buf + bc->tail); ++ ret = local_ev_byte_channel_send(bc->handle, &len, bc->buf + bc->tail); + + /* 'len' is valid only if the return code is 0 or EV_EAGAIN */ + if (!ret || (ret == EV_EAGAIN)) diff --git a/queue-4.9/x86-cpu-add-native-cpuid-variants-returning-a-single-datum.patch b/queue-4.9/x86-cpu-add-native-cpuid-variants-returning-a-single-datum.patch new file mode 100644 index 00000000000..c8bd611369a --- /dev/null +++ b/queue-4.9/x86-cpu-add-native-cpuid-variants-returning-a-single-datum.patch @@ -0,0 +1,48 @@ +From 5dedade6dfa243c130b85d1e4daba6f027805033 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Mon, 9 Jan 2017 12:41:43 +0100 +Subject: x86/CPU: Add native CPUID variants returning a single datum + +From: Borislav Petkov + +commit 5dedade6dfa243c130b85d1e4daba6f027805033 upstream. + +... similarly to the cpuid_() variants. + +Signed-off-by: Borislav Petkov +Link: http://lkml.kernel.org/r/20170109114147.5082-2-bp@alien8.de +Signed-off-by: Thomas Gleixner +Cc: Evalds Iodzevics +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/processor.h | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +--- a/arch/x86/include/asm/processor.h ++++ b/arch/x86/include/asm/processor.h +@@ -213,6 +213,24 @@ static inline void native_cpuid(unsigned + : "memory"); + } + ++#define native_cpuid_reg(reg) \ ++static inline unsigned int native_cpuid_##reg(unsigned int op) \ ++{ \ ++ unsigned int eax = op, ebx, ecx = 0, edx; \ ++ \ ++ native_cpuid(&eax, &ebx, &ecx, &edx); \ ++ \ ++ return reg; \ ++} ++ ++/* ++ * Native CPUID functions returning a single datum. ++ */ ++native_cpuid_reg(eax) ++native_cpuid_reg(ebx) ++native_cpuid_reg(ecx) ++native_cpuid_reg(edx) ++ + static inline void load_cr3(pgd_t *pgdir) + { + write_cr3(__pa(pgdir)); diff --git a/queue-4.9/x86-microcode-intel-replace-sync_core-with-native_cpuid_reg-eax.patch b/queue-4.9/x86-microcode-intel-replace-sync_core-with-native_cpuid_reg-eax.patch new file mode 100644 index 00000000000..9a8cb43226e --- /dev/null +++ b/queue-4.9/x86-microcode-intel-replace-sync_core-with-native_cpuid_reg-eax.patch @@ -0,0 +1,40 @@ +From evalds.iodzevics@gmail.com Wed Apr 22 10:26:17 2020 +From: Evalds Iodzevics +Date: Wed, 22 Apr 2020 11:17:59 +0300 +Subject: x86/microcode/intel: replace sync_core() with native_cpuid_reg(eax) +To: linux-kernel@vger.kernel.org +Cc: gregkh@linuxfoundation.org, tglx@linutronix.de, ben@decadent.org.uk, bp@suse.de, Evalds Iodzevics , stable@vger.kernel.org +Message-ID: <20200422081759.1632-1-evalds.iodzevics@gmail.com> + +From: Evalds Iodzevics + +On Intel it is required to do CPUID(1) before reading the microcode +revision MSR. Current code in 4.4 an 4.9 relies on sync_core() to call +CPUID, unfortunately on 32 bit machines code inside sync_core() always +jumps past CPUID instruction as it depends on data structure boot_cpu_data +witch are not populated correctly so early in boot sequence. + +It depends on: +commit 5dedade6dfa2 ("x86/CPU: Add native CPUID variants returning a single +datum") + +This patch is for 4.4 but also should apply to 4.9 + +Signed-off-by: Evalds Iodzevics +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/microcode_intel.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/include/asm/microcode_intel.h ++++ b/arch/x86/include/asm/microcode_intel.h +@@ -59,7 +59,7 @@ static inline u32 intel_get_microcode_re + native_wrmsrl(MSR_IA32_UCODE_REV, 0); + + /* As documented in the SDM: Do a CPUID 1 here */ +- sync_core(); ++ native_cpuid_eax(1); + + /* get the current revision from MSR 0x8B */ + native_rdmsr(MSR_IA32_UCODE_REV, dummy, rev); diff --git a/queue-4.9/x86-vdso-fix-lsl-operand-order.patch b/queue-4.9/x86-vdso-fix-lsl-operand-order.patch new file mode 100644 index 00000000000..c46d3ffa72f --- /dev/null +++ b/queue-4.9/x86-vdso-fix-lsl-operand-order.patch @@ -0,0 +1,37 @@ +From e78e5a91456fcecaa2efbb3706572fe043766f4d Mon Sep 17 00:00:00 2001 +From: Samuel Neves +Date: Sat, 1 Sep 2018 21:14:52 +0100 +Subject: x86/vdso: Fix lsl operand order + +From: Samuel Neves + +commit e78e5a91456fcecaa2efbb3706572fe043766f4d upstream. + +In the __getcpu function, lsl is using the wrong target and destination +registers. Luckily, the compiler tends to choose %eax for both variables, +so it has been working so far. + +Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available") +Signed-off-by: Samuel Neves +Signed-off-by: Thomas Gleixner +Acked-by: Andy Lutomirski +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20180901201452.27828-1-sneves@dei.uc.pt +Signed-off-by: Nobuhiro Iwamatsu (CIP) +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/vgtod.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/include/asm/vgtod.h ++++ b/arch/x86/include/asm/vgtod.h +@@ -92,7 +92,7 @@ static inline unsigned int __getcpu(void + * + * If RDPID is available, use it. + */ +- alternative_io ("lsl %[p],%[seg]", ++ alternative_io ("lsl %[seg],%[p]", + ".byte 0xf3,0x0f,0xc7,0xf8", /* RDPID %eax/rax */ + X86_FEATURE_RDPID, + [p] "=a" (p), [seg] "r" (__PER_CPU_SEG));