From: Greg Kroah-Hartman Date: Tue, 10 Oct 2017 14:26:58 +0000 (+0200) Subject: 4.13-stable patches X-Git-Tag: v3.18.75~21 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=23865d24ab5c4531e0f75df79de0ce80c651cbea;p=thirdparty%2Fkernel%2Fstable-queue.git 4.13-stable patches added patches: powerpc-64s-use-emergency-stack-for-kernel-tm-bad-thing-program-checks.patch powerpc-fix-action-argument-for-cpufeatures-based-tlb-flush.patch powerpc-powernv-increase-memory-block-size-to-1gb-on-radix.patch powerpc-tm-fix-illegal-tm-state-in-signal-handler.patch --- diff --git a/queue-4.13/powerpc-64s-use-emergency-stack-for-kernel-tm-bad-thing-program-checks.patch b/queue-4.13/powerpc-64s-use-emergency-stack-for-kernel-tm-bad-thing-program-checks.patch new file mode 100644 index 00000000000..2403faa07a8 --- /dev/null +++ b/queue-4.13/powerpc-64s-use-emergency-stack-for-kernel-tm-bad-thing-program-checks.patch @@ -0,0 +1,77 @@ +From 265e60a170d0a0ecfc2d20490134ed2c48dd45ab Mon Sep 17 00:00:00 2001 +From: Cyril Bur +Date: Thu, 17 Aug 2017 20:42:26 +1000 +Subject: powerpc/64s: Use emergency stack for kernel TM Bad Thing program checks + +From: Cyril Bur + +commit 265e60a170d0a0ecfc2d20490134ed2c48dd45ab upstream. + +When using transactional memory (TM), the CPU can be in one of six +states as far as TM is concerned, encoded in the Machine State +Register (MSR). Certain state transitions are illegal and if attempted +trigger a "TM Bad Thing" type program check exception. + +If we ever hit one of these exceptions it's treated as a bug, ie. we +oops, and kill the process and/or panic, depending on configuration. + +One case where we can trigger a TM Bad Thing, is when returning to +userspace after a system call or interrupt, using RFID. When this +happens the CPU first restores the user register state, in particular +r1 (the stack pointer) and then attempts to update the MSR. However +the MSR update is not allowed and so we take the program check with +the user register state, but the kernel MSR. + +This tricks the exception entry code into thinking we have a bad +kernel stack pointer, because the MSR says we're coming from the +kernel, but r1 is pointing to userspace. + +To avoid this we instead always switch to the emergency stack if we +take a TM Bad Thing from the kernel. That way none of the user +register values are used, other than for printing in the oops message. + +This is the fix for CVE-2017-1000255. + +Fixes: 5d176f751ee3 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace") +Signed-off-by: Cyril Bur +[mpe: Rewrite change log & comments, tweak asm slightly] +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/exceptions-64s.S | 24 +++++++++++++++++++++++- + 1 file changed, 23 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/kernel/exceptions-64s.S ++++ b/arch/powerpc/kernel/exceptions-64s.S +@@ -734,7 +734,29 @@ EXC_REAL(program_check, 0x700, 0x100) + EXC_VIRT(program_check, 0x4700, 0x100, 0x700) + TRAMP_KVM(PACA_EXGEN, 0x700) + EXC_COMMON_BEGIN(program_check_common) +- EXCEPTION_PROLOG_COMMON(0x700, PACA_EXGEN) ++ /* ++ * It's possible to receive a TM Bad Thing type program check with ++ * userspace register values (in particular r1), but with SRR1 reporting ++ * that we came from the kernel. Normally that would confuse the bad ++ * stack logic, and we would report a bad kernel stack pointer. Instead ++ * we switch to the emergency stack if we're taking a TM Bad Thing from ++ * the kernel. ++ */ ++ li r10,MSR_PR /* Build a mask of MSR_PR .. */ ++ oris r10,r10,0x200000@h /* .. and SRR1_PROGTM */ ++ and r10,r10,r12 /* Mask SRR1 with that. */ ++ srdi r10,r10,8 /* Shift it so we can compare */ ++ cmpldi r10,(0x200000 >> 8) /* .. with an immediate. */ ++ bne 1f /* If != go to normal path. */ ++ ++ /* SRR1 had PR=0 and SRR1_PROGTM=1, so use the emergency stack */ ++ andi. r10,r12,MSR_PR; /* Set CR0 correctly for label */ ++ /* 3 in EXCEPTION_PROLOG_COMMON */ ++ mr r10,r1 /* Save r1 */ ++ ld r1,PACAEMERGSP(r13) /* Use emergency stack */ ++ subi r1,r1,INT_FRAME_SIZE /* alloc stack frame */ ++ b 3f /* Jump into the macro !! */ ++1: EXCEPTION_PROLOG_COMMON(0x700, PACA_EXGEN) + bl save_nvgprs + RECONCILE_IRQ_STATE(r10, r11) + addi r3,r1,STACK_FRAME_OVERHEAD diff --git a/queue-4.13/powerpc-fix-action-argument-for-cpufeatures-based-tlb-flush.patch b/queue-4.13/powerpc-fix-action-argument-for-cpufeatures-based-tlb-flush.patch new file mode 100644 index 00000000000..0bc89a12ea2 --- /dev/null +++ b/queue-4.13/powerpc-fix-action-argument-for-cpufeatures-based-tlb-flush.patch @@ -0,0 +1,44 @@ +From 3b7af5c0fd9631762d1c4d7b4cee76f571dd3c2c Mon Sep 17 00:00:00 2001 +From: Jeremy Kerr +Date: Wed, 27 Sep 2017 12:55:51 +0800 +Subject: powerpc: Fix action argument for cpufeatures-based TLB flush + +From: Jeremy Kerr + +commit 3b7af5c0fd9631762d1c4d7b4cee76f571dd3c2c upstream. + +Commit 41d0c2ecde19 ("powerpc/powernv: Fix local TLB flush for boot +and MCE on POWER9") introduced calls to __flush_tlb_power[89] from the +cpufeatures code, specifying the number of sets to flush. + +However, these functions take an action argument, not a number of +sets. This means we hit the BUG() in __flush_tlb_{206,300} when using +cpufeatures-style configuration. + +This change passes TLB_INVAL_SCOPE_GLOBAL instead. + +Fixes: 41d0c2ecde19 ("powerpc/powernv: Fix local TLB flush for boot and MCE on POWER9") +Signed-off-by: Jeremy Kerr +Reviewed-by: Nicholas Piggin +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/dt_cpu_ftrs.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/powerpc/kernel/dt_cpu_ftrs.c ++++ b/arch/powerpc/kernel/dt_cpu_ftrs.c +@@ -102,10 +102,10 @@ static void cpufeatures_flush_tlb(void) + case PVR_POWER8: + case PVR_POWER8E: + case PVR_POWER8NVL: +- __flush_tlb_power8(POWER8_TLB_SETS); ++ __flush_tlb_power8(TLB_INVAL_SCOPE_GLOBAL); + break; + case PVR_POWER9: +- __flush_tlb_power9(POWER9_TLB_SETS_HASH); ++ __flush_tlb_power9(TLB_INVAL_SCOPE_GLOBAL); + break; + default: + pr_err("unknown CPU version for boot TLB flush\n"); diff --git a/queue-4.13/powerpc-powernv-increase-memory-block-size-to-1gb-on-radix.patch b/queue-4.13/powerpc-powernv-increase-memory-block-size-to-1gb-on-radix.patch new file mode 100644 index 00000000000..2a743a4b310 --- /dev/null +++ b/queue-4.13/powerpc-powernv-increase-memory-block-size-to-1gb-on-radix.patch @@ -0,0 +1,47 @@ +From 53ecde0b9126ff140abe3aefd7f0ec64d6fa36b0 Mon Sep 17 00:00:00 2001 +From: Anton Blanchard +Date: Thu, 7 Sep 2017 15:05:51 +1000 +Subject: powerpc/powernv: Increase memory block size to 1GB on radix + +From: Anton Blanchard + +commit 53ecde0b9126ff140abe3aefd7f0ec64d6fa36b0 upstream. + +Memory hot unplug on PowerNV radix hosts is broken. Our memory block +size is 256MB but since we map the linear region with very large +pages, each pte we tear down maps 1GB. + +A hot unplug of one 256MB memory block results in 768MB of memory +getting unintentionally unmapped. At this point we are likely to oops. + +Fix this by increasing our memory block size to 1GB on PowerNV radix +hosts. + +Fixes: 4b5d62ca17a1 ("powerpc/mm: add radix__remove_section_mapping()") +Signed-off-by: Anton Blanchard +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/platforms/powernv/setup.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/platforms/powernv/setup.c ++++ b/arch/powerpc/platforms/powernv/setup.c +@@ -272,7 +272,15 @@ static void pnv_kexec_cpu_down(int crash + #ifdef CONFIG_MEMORY_HOTPLUG_SPARSE + static unsigned long pnv_memory_block_size(void) + { +- return 256UL * 1024 * 1024; ++ /* ++ * We map the kernel linear region with 1GB large pages on radix. For ++ * memory hot unplug to work our memory block size must be at least ++ * this size. ++ */ ++ if (radix_enabled()) ++ return 1UL * 1024 * 1024 * 1024; ++ else ++ return 256UL * 1024 * 1024; + } + #endif + diff --git a/queue-4.13/powerpc-tm-fix-illegal-tm-state-in-signal-handler.patch b/queue-4.13/powerpc-tm-fix-illegal-tm-state-in-signal-handler.patch new file mode 100644 index 00000000000..a71e4c6c0e4 --- /dev/null +++ b/queue-4.13/powerpc-tm-fix-illegal-tm-state-in-signal-handler.patch @@ -0,0 +1,62 @@ +From 044215d145a7a8a60ffa8fdc859d110a795fa6ea Mon Sep 17 00:00:00 2001 +From: Gustavo Romero +Date: Tue, 22 Aug 2017 17:20:09 -0400 +Subject: powerpc/tm: Fix illegal TM state in signal handler + +From: Gustavo Romero + +commit 044215d145a7a8a60ffa8fdc859d110a795fa6ea upstream. + +Currently it's possible that on returning from the signal handler +through the restore_tm_sigcontexts() code path (e.g. from a signal +caught due to a `trap` instruction executed in the middle of an HTM +block, or a deliberately constructed sigframe) an illegal TM state +(like TS=10 TM=0, i.e. "T0") is set in SRR1 and when `rfid` sets +implicitly the MSR register from SRR1 register on return to userspace +it causes a TM Bad Thing exception. + +That illegal state can be set (a) by a malicious user that disables +the TM bit by tweaking the bits in uc_mcontext before returning from +the signal handler or (b) by a sufficient number of context switches +occurring such that the load_tm counter overflows and TM is disabled +whilst in the signal handler. + +This commit fixes the illegal TM state by ensuring that TM bit is +always enabled before we return from restore_tm_sigcontexts(). A small +comment correction is made as well. + +Fixes: 5d176f751ee3 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace") +Signed-off-by: Gustavo Romero +Signed-off-by: Breno Leitao +Signed-off-by: Cyril Bur +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/signal_64.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/kernel/signal_64.c ++++ b/arch/powerpc/kernel/signal_64.c +@@ -452,9 +452,20 @@ static long restore_tm_sigcontexts(struc + if (MSR_TM_RESV(msr)) + return -EINVAL; + +- /* pull in MSR TM from user context */ ++ /* pull in MSR TS bits from user context */ + regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr & MSR_TS_MASK); + ++ /* ++ * Ensure that TM is enabled in regs->msr before we leave the signal ++ * handler. It could be the case that (a) user disabled the TM bit ++ * through the manipulation of the MSR bits in uc_mcontext or (b) the ++ * TM bit was disabled because a sufficient number of context switches ++ * happened whilst in the signal handler and load_tm overflowed, ++ * disabling the TM bit. In either case we can end up with an illegal ++ * TM state leading to a TM Bad Thing when we return to userspace. ++ */ ++ regs->msr |= MSR_TM; ++ + /* pull in MSR LE from user context */ + regs->msr = (regs->msr & ~MSR_LE) | (msr & MSR_LE); + diff --git a/queue-4.13/series b/queue-4.13/series index 4655b415258..004f58e6af4 100644 --- a/queue-4.13/series +++ b/queue-4.13/series @@ -105,3 +105,7 @@ lsm-fix-smack_inode_removexattr-and-xattr_getsecurity-memleak.patch alsa-compress-remove-unused-variable.patch revert-alsa-echoaudio-purge-contradictions-between-dimension-matrix-members-and-total-number-of-members.patch alsa-usx2y-suppress-kernel-warning-at-page-allocation-failures.patch +powerpc-powernv-increase-memory-block-size-to-1gb-on-radix.patch +powerpc-fix-action-argument-for-cpufeatures-based-tlb-flush.patch +powerpc-64s-use-emergency-stack-for-kernel-tm-bad-thing-program-checks.patch +powerpc-tm-fix-illegal-tm-state-in-signal-handler.patch