Home Home > GIT Browse
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKernel Build Daemon <kbuild@suse.de>2019-09-20 07:06:20 +0200
committerKernel Build Daemon <kbuild@suse.de>2019-09-20 07:06:20 +0200
commit6d6e404a733f79f7b8d3abdc0ce7def761318dcc (patch)
tree26fe558b635d80d5613f948fe7411bb06c599037
parent643bef099d7792fe2c015224e7809e0c496b161c (diff)
parentf4acd955772c2c5d498b0ba420cebc34d511f814 (diff)
Merge branch 'SLE12-SP5' into SLE12-SP5-AZURE
-rw-r--r--patches.suse/USB-yurex-Fix-protection-fault-after-device-removal.patch2
-rw-r--r--patches.suse/fm10k-Fix-a-potential-NULL-pointer-dereference.patch2
-rw-r--r--patches.suse/powerpc-tm-Fix-FP-VMX-unavailable-exceptions-inside-.patch115
-rw-r--r--patches.suse/powerpc-tm-Fix-restoring-FP-VMX-facility-incorrectly.patch139
-rw-r--r--patches.suse/vhost-make-sure-log_num-in_num.patch58
-rw-r--r--series.conf5
6 files changed, 319 insertions, 2 deletions
diff --git a/patches.suse/USB-yurex-Fix-protection-fault-after-device-removal.patch b/patches.suse/USB-yurex-Fix-protection-fault-after-device-removal.patch
index 31cc850efb..3b7b1a8351 100644
--- a/patches.suse/USB-yurex-Fix-protection-fault-after-device-removal.patch
+++ b/patches.suse/USB-yurex-Fix-protection-fault-after-device-removal.patch
@@ -4,7 +4,7 @@ Date: Tue, 23 Apr 2019 14:48:29 -0400
Subject: [PATCH] USB: yurex: Fix protection fault after device removal
Git-commit: ef61eb43ada6c1d6b94668f0f514e4c268093ff3
Patch-mainline: v5.1
-References: bsc#1051510
+References: bsc#1146361 CVE-2019-15216
The syzkaller USB fuzzer found a general-protection-fault bug in the
yurex driver. The fault occurs when a device has been unplugged; the
diff --git a/patches.suse/fm10k-Fix-a-potential-NULL-pointer-dereference.patch b/patches.suse/fm10k-Fix-a-potential-NULL-pointer-dereference.patch
index dfae3b3fcf..c2ac18bb87 100644
--- a/patches.suse/fm10k-Fix-a-potential-NULL-pointer-dereference.patch
+++ b/patches.suse/fm10k-Fix-a-potential-NULL-pointer-dereference.patch
@@ -4,7 +4,7 @@ Date: Thu, 21 Mar 2019 22:42:23 +0800
Subject: [PATCH] fm10k: Fix a potential NULL pointer dereference
Git-commit: 01ca667133d019edc9f0a1f70a272447c84ec41f
Patch-mainline: v5.1-rc4
-References: bsc#1051510
+References: bsc#1051510 bsc#1149612 CVE-2019-15924
Syzkaller report this:
diff --git a/patches.suse/powerpc-tm-Fix-FP-VMX-unavailable-exceptions-inside-.patch b/patches.suse/powerpc-tm-Fix-FP-VMX-unavailable-exceptions-inside-.patch
new file mode 100644
index 0000000000..8063baa785
--- /dev/null
+++ b/patches.suse/powerpc-tm-Fix-FP-VMX-unavailable-exceptions-inside-.patch
@@ -0,0 +1,115 @@
+From 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 Mon Sep 17 00:00:00 2001
+From: Gustavo Romero <gromero@linux.ibm.com>
+Date: Wed, 4 Sep 2019 00:55:27 -0400
+Subject: [PATCH] powerpc/tm: Fix FP/VMX unavailable exceptions inside a
+ transaction
+
+References: CVE-2019-15030 bsc#1149713
+Patch-mainline: queued
+Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
+Git-commit: 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60
+
+When we take an FP unavailable exception in a transaction we have to
+account for the hardware FP TM checkpointed registers being
+incorrect. In this case for this process we know the current and
+checkpointed FP registers must be the same (since FP wasn't used
+inside the transaction) hence in the thread_struct we copy the current
+FP registers to the checkpointed ones.
+
+This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr
+to determine if FP was on when in userspace. thread->ckpt_regs.msr
+represents the state of the MSR when exiting userspace. This is setup
+by check_if_tm_restore_required().
+
+Unfortunatley there is an optimisation in giveup_all() which returns
+early if tsk->thread.regs->msr (via local variable `usermsr`) has
+FP=VEC=VSX=SPE=0. This optimisation means that
+check_if_tm_restore_required() is not called and hence
+thread->ckpt_regs.msr is not updated and will contain an old value.
+
+This can happen if due to load_fp=255 we start a userspace process
+with MSR FP=1 and then we are context switched out. In this case
+thread->ckpt_regs.msr will contain FP=1. If that same process is then
+context switched in and load_fp overflows, MSR will have FP=0. If that
+process now enters a transaction and does an FP instruction, the FP
+unavailable will not update thread->ckpt_regs.msr (the bug) and MSR
+FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread()
+will then not perform the required memcpy and the checkpointed FP regs
+in the thread struct will contain the wrong values.
+
+The code path for this happening is:
+
+ Userspace: Kernel
+ Start userspace
+ with MSR FP/VEC/VSX/SPE=0 TM=1
+ < -----
+ ...
+ tbegin
+ bne
+ fp instruction
+ FP unavailable
+ ---- >
+ fp_unavailable_tm()
+ tm_reclaim_current()
+ tm_reclaim_thread()
+ giveup_all()
+ return early since FP/VMX/VSX=0
+ /* ckpt MSR not updated (Incorrect) */
+ tm_reclaim()
+ /* thread_struct ckpt FP regs contain junk (OK) */
+ /* Sees ckpt MSR FP=1 (Incorrect) */
+ no memcpy() performed
+ /* thread_struct ckpt FP regs not fixed (Incorrect) */
+ tm_recheckpoint()
+ /* Put junk in hardware checkpoint FP regs */
+ ....
+ < -----
+ Return to userspace
+ with MSR TM=1 FP=1
+ with junk in the FP TM checkpoint
+ TM rollback
+ reads FP junk
+
+This is a data integrity problem for the current process as the FP
+registers are corrupted. It's also a security problem as the FP
+registers from one process may be leaked to another.
+
+This patch moves up check_if_tm_restore_required() in giveup_all() to
+ensure thread->ckpt_regs.msr is updated correctly.
+
+A simple testcase to replicate this will be posted to
+tools/testing/selftests/powerpc/tm/tm-poison.c
+
+Similarly for VMX.
+
+This fixes CVE-2019-15030.
+
+Fixes: f48e91e87e67 ("powerpc/tm: Fix FP and VMX register corruption")
+Cc: stable@vger.kernel.org # 4.12+
+Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com>
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com
+Acked-by: Michal Suchanek <msuchanek@suse.de>
+---
+ arch/powerpc/kernel/process.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/kernel/process.c
++++ b/arch/powerpc/kernel/process.c
+@@ -495,13 +495,14 @@ void giveup_all(struct task_struct *tsk)
+ if (!tsk->thread.regs)
+ return;
+
++ check_if_tm_restore_required(tsk);
++
+ usermsr = tsk->thread.regs->msr;
+
+ if ((usermsr & msr_all_available) == 0)
+ return;
+
+ msr_check_and_set(msr_all_available);
+- check_if_tm_restore_required(tsk);
+
+ #ifdef CONFIG_PPC_FPU
+ if (usermsr & MSR_FP)
diff --git a/patches.suse/powerpc-tm-Fix-restoring-FP-VMX-facility-incorrectly.patch b/patches.suse/powerpc-tm-Fix-restoring-FP-VMX-facility-incorrectly.patch
new file mode 100644
index 0000000000..f7c57be397
--- /dev/null
+++ b/patches.suse/powerpc-tm-Fix-restoring-FP-VMX-facility-incorrectly.patch
@@ -0,0 +1,139 @@
+From a8318c13e79badb92bc6640704a64cc022a6eb97 Mon Sep 17 00:00:00 2001
+From: Gustavo Romero <gromero@linux.ibm.com>
+Date: Wed, 4 Sep 2019 00:55:28 -0400
+Subject: [PATCH] powerpc/tm: Fix restoring FP/VMX facility incorrectly on
+ interrupts
+
+References: CVE-2019-15031 bsc#1149713
+Patch-mainline: queued
+Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
+Git-commit: a8318c13e79badb92bc6640704a64cc022a6eb97
+
+When in userspace and MSR FP=0 the hardware FP state is unrelated to
+the current process. This is extended for transactions where if tbegin
+is run with FP=0, the hardware checkpoint FP state will also be
+unrelated to the current process. Due to this, we need to ensure this
+hardware checkpoint is updated with the correct state before we enable
+FP for this process.
+
+Unfortunately we get this wrong when returning to a process from a
+hardware interrupt. A process that starts a transaction with FP=0 can
+take an interrupt. When the kernel returns back to that process, we
+change to FP=1 but with hardware checkpoint FP state not updated. If
+this transaction is then rolled back, the FP registers now contain the
+wrong state.
+
+The process looks like this:
+ Userspace: Kernel
+
+ Start userspace
+ with MSR FP=0 TM=1
+ < -----
+ ...
+ tbegin
+ bne
+ Hardware interrupt
+ ---- >
+ <do_IRQ...>
+ ....
+ ret_from_except
+ restore_math()
+ /* sees FP=0 */
+ restore_fp()
+ tm_active_with_fp()
+ /* sees FP=1 (Incorrect) */
+ load_fp_state()
+ FP = 0 -> 1
+ < -----
+ Return to userspace
+ with MSR TM=1 FP=1
+ with junk in the FP TM checkpoint
+ TM rollback
+ reads FP junk
+
+When returning from the hardware exception, tm_active_with_fp() is
+incorrectly making restore_fp() call load_fp_state() which is setting
+FP=1.
+
+The fix is to remove tm_active_with_fp().
+
+tm_active_with_fp() is attempting to handle the case where FP state
+has been changed inside a transaction. In this case the checkpointed
+and transactional FP state is different and hence we must restore the
+FP state (ie. we can't do lazy FP restore inside a transaction that's
+used FP). It's safe to remove tm_active_with_fp() as this case is
+handled by restore_tm_state(). restore_tm_state() detects if FP has
+been using inside a transaction and will set load_fp and call
+restore_math() to ensure the FP state (checkpoint and transaction) is
+restored.
+
+This is a data integrity problem for the current process as the FP
+registers are corrupted. It's also a security problem as the FP
+registers from one process may be leaked to another.
+
+Similarly for VMX.
+
+A simple testcase to replicate this will be posted to
+tools/testing/selftests/powerpc/tm/tm-poison.c
+
+This fixes CVE-2019-15031.
+
+Fixes: a7771176b439 ("powerpc: Don't enable FP/Altivec if not checkpointed")
+Cc: stable@vger.kernel.org # 4.15+
+Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.com
+Acked-by: Michal Suchanek <msuchanek@suse.de>
+---
+ arch/powerpc/kernel/process.c | 18 ++----------------
+ 1 file changed, 2 insertions(+), 16 deletions(-)
+
+diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
+index 437b57068cf8..7a84c9f1778e 100644
+--- a/arch/powerpc/kernel/process.c
++++ b/arch/powerpc/kernel/process.c
+@@ -101,21 +101,8 @@ static void check_if_tm_restore_required(struct task_struct *tsk)
+ }
+ }
+
+-static bool tm_active_with_fp(struct task_struct *tsk)
+-{
+- return MSR_TM_ACTIVE(tsk->thread.regs->msr) &&
+- (tsk->thread.ckpt_regs.msr & MSR_FP);
+-}
+-
+-static bool tm_active_with_altivec(struct task_struct *tsk)
+-{
+- return MSR_TM_ACTIVE(tsk->thread.regs->msr) &&
+- (tsk->thread.ckpt_regs.msr & MSR_VEC);
+-}
+ #else
+ static inline void check_if_tm_restore_required(struct task_struct *tsk) { }
+-static inline bool tm_active_with_fp(struct task_struct *tsk) { return false; }
+-static inline bool tm_active_with_altivec(struct task_struct *tsk) { return false; }
+ #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+
+ bool strict_msr_control;
+@@ -252,7 +239,7 @@ EXPORT_SYMBOL(enable_kernel_fp);
+
+ static int restore_fp(struct task_struct *tsk)
+ {
+- if (tsk->thread.load_fp || tm_active_with_fp(tsk)) {
++ if (tsk->thread.load_fp) {
+ load_fp_state(&current->thread.fp_state);
+ current->thread.load_fp++;
+ return 1;
+@@ -334,8 +321,7 @@ EXPORT_SYMBOL_GPL(flush_altivec_to_thread);
+
+ static int restore_altivec(struct task_struct *tsk)
+ {
+- if (cpu_has_feature(CPU_FTR_ALTIVEC) &&
+- (tsk->thread.load_vec || tm_active_with_altivec(tsk))) {
++ if (cpu_has_feature(CPU_FTR_ALTIVEC) && (tsk->thread.load_vec)) {
+ load_vr_state(&tsk->thread.vr_state);
+ tsk->thread.used_vr = 1;
+ tsk->thread.load_vec++;
+--
+2.22.0
+
diff --git a/patches.suse/vhost-make-sure-log_num-in_num.patch b/patches.suse/vhost-make-sure-log_num-in_num.patch
new file mode 100644
index 0000000000..a2a976c2fa
--- /dev/null
+++ b/patches.suse/vhost-make-sure-log_num-in_num.patch
@@ -0,0 +1,58 @@
+From 060423bfdee3f8bc6e2c1bac97de24d5415e2bc4 Mon Sep 17 00:00:00 2001
+From: yongduan <yongduan@tencent.com>
+Date: Wed, 11 Sep 2019 17:44:24 +0800
+Subject: [PATCH] vhost: make sure log_num < in_num
+Git-commit: 060423bfdee3f8bc6e2c1bac97de24d5415e2bc4
+Patch-mainline: v5.3
+References: bsc#1150112,CVE-2019-14835
+
+The code assumes log_num < in_num everywhere, and that is true as long as
+in_num is incremented by descriptor iov count, and log_num by 1. However
+this breaks if there's a zero sized descriptor.
+
+As a result, if a malicious guest creates a vring desc with desc.len = 0,
+it may cause the host kernel to crash by overflowing the log array. This
+bug can be triggered during the VM migration.
+
+There's no need to log when desc.len = 0, so just don't increment log_num
+in this case.
+
+Fixes: 3a4d5c94e959 ("vhost_net: a kernel-level virtio server")
+Cc: stable@vger.kernel.org
+Reviewed-by: Lidong Chen <lidongchen@tencent.com>
+Signed-off-by: ruippan <ruippan@tencent.com>
+Signed-off-by: yongduan <yongduan@tencent.com>
+Acked-by: Michael S. Tsirkin <mst@redhat.com>
+Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Acked-by: Takashi Iwai <tiwai@suse.de>
+Acked-by: Denis Kirjanov <dkirjanov@suse.com>
+---
+ drivers/vhost/vhost.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
+index 34ea219936e3..acabf20b069e 100644
+--- a/drivers/vhost/vhost.c
++++ b/drivers/vhost/vhost.c
+@@ -2180,7 +2180,7 @@ static int get_indirect(struct vhost_virtqueue *vq,
+ /* If this is an input descriptor, increment that count. */
+ if (access == VHOST_ACCESS_WO) {
+ *in_num += ret;
+- if (unlikely(log)) {
++ if (unlikely(log && ret)) {
+ log[*log_num].addr = vhost64_to_cpu(vq, desc.addr);
+ log[*log_num].len = vhost32_to_cpu(vq, desc.len);
+ ++*log_num;
+@@ -2321,7 +2321,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
+ /* If this is an input descriptor,
+ * increment that count. */
+ *in_num += ret;
+- if (unlikely(log)) {
++ if (unlikely(log && ret)) {
+ log[*log_num].addr = vhost64_to_cpu(vq, desc.addr);
+ log[*log_num].len = vhost32_to_cpu(vq, desc.len);
+ ++*log_num;
+--
+2.16.4
+
diff --git a/series.conf b/series.conf
index bdfdf8a12b..ac628e2bbb 100644
--- a/series.conf
+++ b/series.conf
@@ -49770,6 +49770,7 @@
patches.suse/usb-host-xhci-rcar-Fix-typo-in-compatible-string-mat.patch
patches.suse/USB-cdc-wdm-fix-race-between-write-and-disconnect-du.patch
patches.suse/VMCI-Release-resource-if-the-work-is-already-queued.patch
+ patches.suse/vhost-make-sure-log_num-in_num.patch
# jejb/scsi for-next
patches.suse/scsi-cxlflash-Mark-expected-switch-fall-throughs.patch
@@ -49823,6 +49824,10 @@
patches.suse/powerpc-rtas-use-device-model-APIs-and-serialization.patch
patches.suse/powerpc-64s-support-nospectre_v2-cmdline-option.patch
+ # powerpc/linux fixes
+ patches.suse/powerpc-tm-Fix-FP-VMX-unavailable-exceptions-inside-.patch
+ patches.suse/powerpc-tm-Fix-restoring-FP-VMX-facility-incorrectly.patch
+
# tip/tip
patches.suse/x86-kconfig-remove-x86_direct_gbpages-dependency-on-debug_pagealloc.patch