]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.18-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 13 Feb 2019 10:03:59 +0000 (11:03 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 13 Feb 2019 10:03:59 +0000 (11:03 +0100)
added patches:
debugfs-fix-debugfs_rename-parameter-checking.patch
mei-me-add-ice-lake-point-device-id.patch
misc-vexpress-off-by-one-in-vexpress_syscfg_exec.patch
mtd-rawnand-gpmi-fix-mx28-bus-master-lockup-problem.patch
signal-always-notice-exiting-tasks.patch
signal-better-detection-of-synchronous-signals.patch

queue-3.18/debugfs-fix-debugfs_rename-parameter-checking.patch [new file with mode: 0644]
queue-3.18/mei-me-add-ice-lake-point-device-id.patch [new file with mode: 0644]
queue-3.18/misc-vexpress-off-by-one-in-vexpress_syscfg_exec.patch [new file with mode: 0644]
queue-3.18/mtd-rawnand-gpmi-fix-mx28-bus-master-lockup-problem.patch [new file with mode: 0644]
queue-3.18/series
queue-3.18/signal-always-notice-exiting-tasks.patch [new file with mode: 0644]
queue-3.18/signal-better-detection-of-synchronous-signals.patch [new file with mode: 0644]

diff --git a/queue-3.18/debugfs-fix-debugfs_rename-parameter-checking.patch b/queue-3.18/debugfs-fix-debugfs_rename-parameter-checking.patch
new file mode 100644 (file)
index 0000000..354d8a1
--- /dev/null
@@ -0,0 +1,39 @@
+From d88c93f090f708c18195553b352b9f205e65418f Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Wed, 23 Jan 2019 11:27:02 +0100
+Subject: debugfs: fix debugfs_rename parameter checking
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit d88c93f090f708c18195553b352b9f205e65418f upstream.
+
+debugfs_rename() needs to check that the dentries passed into it really
+are valid, as sometimes they are not (i.e. if the return value of
+another debugfs call is passed into this one.)  So fix this up by
+properly checking if the two parent directories are errors (they are
+allowed to be NULL), and if the dentry to rename is not NULL or an
+error.
+
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/debugfs/inode.c |    7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/fs/debugfs/inode.c
++++ b/fs/debugfs/inode.c
+@@ -622,6 +622,13 @@ struct dentry *debugfs_rename(struct den
+       struct dentry *dentry = NULL, *trap;
+       struct name_snapshot old_name;
++      if (IS_ERR(old_dir))
++              return old_dir;
++      if (IS_ERR(new_dir))
++              return new_dir;
++      if (IS_ERR_OR_NULL(old_dentry))
++              return old_dentry;
++
+       trap = lock_rename(new_dir, old_dir);
+       /* Source or destination directories don't exist? */
+       if (!old_dir->d_inode || !new_dir->d_inode)
diff --git a/queue-3.18/mei-me-add-ice-lake-point-device-id.patch b/queue-3.18/mei-me-add-ice-lake-point-device-id.patch
new file mode 100644 (file)
index 0000000..dccfc78
--- /dev/null
@@ -0,0 +1,42 @@
+From efe814e90b98aed6d655b5a4092b9114b8b26e42 Mon Sep 17 00:00:00 2001
+From: Tomas Winkler <tomas.winkler@intel.com>
+Date: Thu, 24 Jan 2019 14:45:02 +0200
+Subject: mei: me: add ice lake point device id.
+
+From: Tomas Winkler <tomas.winkler@intel.com>
+
+commit efe814e90b98aed6d655b5a4092b9114b8b26e42 upstream.
+
+Add icelake mei device id.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/mei/hw-me-regs.h |    2 ++
+ drivers/misc/mei/pci-me.c     |    2 ++
+ 2 files changed, 4 insertions(+)
+
+--- a/drivers/misc/mei/hw-me-regs.h
++++ b/drivers/misc/mei/hw-me-regs.h
+@@ -121,6 +121,8 @@
+ #define PCI_CFG_HFS_1         0x40
+ #define PCI_CFG_HFS_2         0x48
++#define MEI_DEV_ID_ICP_LP     0x34E0  /* Ice Lake Point LP */
++
+ /*
+  * MEI HW Section
+  */
+--- a/drivers/misc/mei/pci-me.c
++++ b/drivers/misc/mei/pci-me.c
+@@ -83,6 +83,8 @@ static const struct pci_device_id mei_me
+       {MEI_PCI_DEVICE(MEI_DEV_ID_WPT_LP, mei_me_pch_cfg)},
+       {MEI_PCI_DEVICE(MEI_DEV_ID_WPT_LP_2, mei_me_pch_cfg)},
++      {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
++
+       /* required last entry */
+       {0, }
+ };
diff --git a/queue-3.18/misc-vexpress-off-by-one-in-vexpress_syscfg_exec.patch b/queue-3.18/misc-vexpress-off-by-one-in-vexpress_syscfg_exec.patch
new file mode 100644 (file)
index 0000000..755ed66
--- /dev/null
@@ -0,0 +1,35 @@
+From f8a70d8b889f180e6860cb1f85fed43d37844c5a Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Mon, 3 Dec 2018 17:52:19 +0300
+Subject: misc: vexpress: Off by one in vexpress_syscfg_exec()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit f8a70d8b889f180e6860cb1f85fed43d37844c5a upstream.
+
+The > comparison should be >= to prevent reading beyond the end of the
+func->template[] array.
+
+(The func->template array is allocated in vexpress_syscfg_regmap_init()
+and it has func->num_templates elements.)
+
+Fixes: 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Acked-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/vexpress-syscfg.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/vexpress-syscfg.c
++++ b/drivers/misc/vexpress-syscfg.c
+@@ -61,7 +61,7 @@ static int vexpress_syscfg_exec(struct v
+       int tries;
+       long timeout;
+-      if (WARN_ON(index > func->num_templates))
++      if (WARN_ON(index >= func->num_templates))
+               return -EINVAL;
+       command = readl(syscfg->base + SYS_CFGCTRL);
diff --git a/queue-3.18/mtd-rawnand-gpmi-fix-mx28-bus-master-lockup-problem.patch b/queue-3.18/mtd-rawnand-gpmi-fix-mx28-bus-master-lockup-problem.patch
new file mode 100644 (file)
index 0000000..0f2b7ed
--- /dev/null
@@ -0,0 +1,86 @@
+From d5d27fd9826b59979b184ec288e4812abac0e988 Mon Sep 17 00:00:00 2001
+From: Martin Kepplinger <martin.kepplinger@ginzinger.com>
+Date: Tue, 5 Feb 2019 16:52:51 +0100
+Subject: mtd: rawnand: gpmi: fix MX28 bus master lockup problem
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Martin Kepplinger <martin.kepplinger@ginzinger.com>
+
+commit d5d27fd9826b59979b184ec288e4812abac0e988 upstream.
+
+Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft
+reset may cause bus master lock up") for MX28 too. It has the same
+problem.
+
+Observed problem: once per 100,000+ MX28 reboots NAND read failed on
+DMA timeout errors:
+[    1.770823] UBI: attaching mtd3 to ubi0
+[    2.768088] gpmi_nand: DMA timeout, last DMA :1
+[    3.958087] gpmi_nand: BCH timeout, last DMA :1
+[    4.156033] gpmi_nand: Error in ECC-based read: -110
+[    4.161136] UBI warning: ubi_io_read: error -110 while reading 64
+bytes from PEB 0:0, read only 0 bytes, retry
+[    4.171283] step 1 error
+[    4.173846] gpmi_nand: Chip: 0, Error -1
+
+Without BCH soft reset we successfully executed 1,000,000 MX28 reboots.
+
+I have a quote from NXP regarding this problem, from July 18th 2016:
+
+"As the i.MX23 and i.MX28 are of the same generation, they share many
+characteristics. Unfortunately, also the erratas may be shared.
+In case of the documented erratas and the workarounds, you can also
+apply the workaround solution of one device on the other one. This have
+been reported, but I’m afraid that there are not an estimated date for
+updating the Errata documents.
+Please accept our apologies for any inconveniences this may cause."
+
+Fixes: 6f2a6a52560a ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems")
+Cc: stable@vger.kernel.org
+Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
+Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Acked-by: Han Xu <han.xu@nxp.com>
+Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   15 +++++++--------
+ 1 file changed, 7 insertions(+), 8 deletions(-)
+
+--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
++++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+@@ -168,9 +168,10 @@ int gpmi_init(struct gpmi_nand_data *thi
+       /*
+        * Reset BCH here, too. We got failures otherwise :(
+-       * See later BCH reset for explanation of MX23 handling
++       * See later BCH reset for explanation of MX23 and MX28 handling
+        */
+-      ret = gpmi_reset_block(r->bch_regs, GPMI_IS_MX23(this));
++      ret = gpmi_reset_block(r->bch_regs,
++                             GPMI_IS_MX23(this) || GPMI_IS_MX28(this));
+       if (ret)
+               goto err_out;
+@@ -274,13 +275,11 @@ int bch_set_geometry(struct gpmi_nand_da
+       /*
+       * Due to erratum #2847 of the MX23, the BCH cannot be soft reset on this
+-      * chip, otherwise it will lock up. So we skip resetting BCH on the MX23.
+-      * On the other hand, the MX28 needs the reset, because one case has been
+-      * seen where the BCH produced ECC errors constantly after 10000
+-      * consecutive reboots. The latter case has not been seen on the MX23
+-      * yet, still we don't know if it could happen there as well.
++      * chip, otherwise it will lock up. So we skip resetting BCH on the MX23
++      * and MX28.
+       */
+-      ret = gpmi_reset_block(r->bch_regs, GPMI_IS_MX23(this));
++      ret = gpmi_reset_block(r->bch_regs,
++                             GPMI_IS_MX23(this) || GPMI_IS_MX28(this));
+       if (ret)
+               goto err_out;
index b8f0ca2e999474ad64e6433bb5df5f600f5d6ef3..f9b473ee390d725d3cd3608560e5e0b9942d329c 100644 (file)
@@ -72,3 +72,9 @@ kvm-nvmx-unconditionally-cancel-preemption-timer-in-free_nested-cve-2019-7221.pa
 perf-x86-intel-uncore-add-node-id-mask.patch
 perf-core-don-t-warn-for-impossible-ring-buffer-sizes.patch
 perf-tests-evsel-tp-sched-fix-bitwise-operator.patch
+mtd-rawnand-gpmi-fix-mx28-bus-master-lockup-problem.patch
+signal-always-notice-exiting-tasks.patch
+signal-better-detection-of-synchronous-signals.patch
+misc-vexpress-off-by-one-in-vexpress_syscfg_exec.patch
+mei-me-add-ice-lake-point-device-id.patch
+debugfs-fix-debugfs_rename-parameter-checking.patch
diff --git a/queue-3.18/signal-always-notice-exiting-tasks.patch b/queue-3.18/signal-always-notice-exiting-tasks.patch
new file mode 100644 (file)
index 0000000..9542683
--- /dev/null
@@ -0,0 +1,65 @@
+From 35634ffa1751b6efd8cf75010b509dcb0263e29b Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Wed, 6 Feb 2019 18:39:40 -0600
+Subject: signal: Always notice exiting tasks
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.
+
+Recently syzkaller was able to create unkillablle processes by
+creating a timer that is delivered as a thread local signal on SIGHUP,
+and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
+failing to deliver SIGHUP but always trying.
+
+Upon examination it turns out part of the problem is actually most of
+the solution.  Since 2.5 signal delivery has found all fatal signals,
+marked the signal group for death, and queued SIGKILL in every threads
+thread queue relying on signal->group_exit_code to preserve the
+information of which was the actual fatal signal.
+
+The conversion of all fatal signals to SIGKILL results in the
+synchronous signal heuristic in next_signal kicking in and preferring
+SIGHUP to SIGKILL.  Which is especially problematic as all
+fatal signals have already been transformed into SIGKILL.
+
+Instead of dequeueing signals and depending upon SIGKILL to
+be the first signal dequeued, first test if the signal group
+has already been marked for death.  This guarantees that
+nothing in the signal queue can prevent a process that needs
+to exit from exiting.
+
+Cc: stable@vger.kernel.org
+Tested-by: Dmitry Vyukov <dvyukov@google.com>
+Reported-by: Dmitry Vyukov <dvyukov@google.com>
+Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
+History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/signal.c |    6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -2241,6 +2241,11 @@ relock:
+               goto relock;
+       }
++      /* Has this task already been marked for death? */
++      ksig->info.si_signo = signr = SIGKILL;
++      if (signal_group_exit(signal))
++              goto fatal;
++
+       for (;;) {
+               struct k_sigaction *ka;
+@@ -2336,6 +2341,7 @@ relock:
+                       continue;
+               }
++      fatal:
+               spin_unlock_irq(&sighand->siglock);
+               /*
diff --git a/queue-3.18/signal-better-detection-of-synchronous-signals.patch b/queue-3.18/signal-better-detection-of-synchronous-signals.patch
new file mode 100644 (file)
index 0000000..8ef2905
--- /dev/null
@@ -0,0 +1,116 @@
+From 7146db3317c67b517258cb5e1b08af387da0618b Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Wed, 6 Feb 2019 17:51:47 -0600
+Subject: signal: Better detection of synchronous signals
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit 7146db3317c67b517258cb5e1b08af387da0618b upstream.
+
+Recently syzkaller was able to create unkillablle processes by
+creating a timer that is delivered as a thread local signal on SIGHUP,
+and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop failing
+to deliver SIGHUP but always trying.
+
+When the stack overflows delivery of SIGHUP fails and force_sigsegv is
+called.  Unfortunately because SIGSEGV is numerically higher than
+SIGHUP next_signal tries again to deliver a SIGHUP.
+
+From a quality of implementation standpoint attempting to deliver the
+timer SIGHUP signal is wrong.  We should attempt to deliver the
+synchronous SIGSEGV signal we just forced.
+
+We can make that happening in a fairly straight forward manner by
+instead of just looking at the signal number we also look at the
+si_code.  In particular for exceptions (aka synchronous signals) the
+si_code is always greater than 0.
+
+That still has the potential to pick up a number of asynchronous
+signals as in a few cases the same si_codes that are used
+for synchronous signals are also used for asynchronous signals,
+and SI_KERNEL is also included in the list of possible si_codes.
+
+Still the heuristic is much better and timer signals are definitely
+excluded.  Which is enough to prevent all known ways for someone
+sending a process signals fast enough to cause unexpected and
+arguably incorrect behavior.
+
+Cc: stable@vger.kernel.org
+Fixes: a27341cd5fcb ("Prioritize synchronous signals over 'normal' signals")
+Tested-by: Dmitry Vyukov <dvyukov@google.com>
+Reported-by: Dmitry Vyukov <dvyukov@google.com>
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/signal.c |   52 +++++++++++++++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 51 insertions(+), 1 deletion(-)
+
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -686,6 +686,48 @@ int dequeue_signal(struct task_struct *t
+       return signr;
+ }
++static int dequeue_synchronous_signal(kernel_siginfo_t *info)
++{
++      struct task_struct *tsk = current;
++      struct sigpending *pending = &tsk->pending;
++      struct sigqueue *q, *sync = NULL;
++
++      /*
++       * Might a synchronous signal be in the queue?
++       */
++      if (!((pending->signal.sig[0] & ~tsk->blocked.sig[0]) & SYNCHRONOUS_MASK))
++              return 0;
++
++      /*
++       * Return the first synchronous signal in the queue.
++       */
++      list_for_each_entry(q, &pending->list, list) {
++              /* Synchronous signals have a postive si_code */
++              if ((q->info.si_code > SI_USER) &&
++                  (sigmask(q->info.si_signo) & SYNCHRONOUS_MASK)) {
++                      sync = q;
++                      goto next;
++              }
++      }
++      return 0;
++next:
++      /*
++       * Check if there is another siginfo for the same signal.
++       */
++      list_for_each_entry_continue(q, &pending->list, list) {
++              if (q->info.si_signo == sync->info.si_signo)
++                      goto still_pending;
++      }
++
++      sigdelset(&pending->signal, sync->info.si_signo);
++      recalc_sigpending();
++still_pending:
++      list_del_init(&sync->list);
++      copy_siginfo(info, &sync->info);
++      __sigqueue_free(sync);
++      return info->si_signo;
++}
++
+ /*
+  * Tell a process that it has a new active signal..
+  *
+@@ -2259,7 +2301,15 @@ relock:
+                       goto relock;
+               }
+-              signr = dequeue_signal(current, &current->blocked, &ksig->info);
++              /*
++               * Signals generated by the execution of an instruction
++               * need to be delivered before any other pending signals
++               * so that the instruction pointer in the signal stack
++               * frame points to the faulting instruction.
++               */
++              signr = dequeue_synchronous_signal(&ksig->info);
++              if (!signr)
++                      signr = dequeue_signal(current, &current->blocked, &ksig->info);
+               if (!signr)
+                       break; /* will return 0 */