From: Greg Kroah-Hartman Date: Sat, 25 Nov 2017 13:54:26 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v3.18.85~55 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9836b14a94c868ac429a22cce115bff65ca5d02a;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: acpi-apei-remove-arch_apei_flush_tlb_one.patch acpi-ec-fix-regression-related-to-triggering-source-of-ec-event-handling.patch s390-disassembler-add-missing-end-marker-for-e7-table.patch s390-disassembler-increase-show_code-buffer-size.patch s390-fix-transactional-execution-control-register-handling.patch s390-runtime-instrumention-fix-possible-memory-corruption.patch --- diff --git a/queue-4.9/acpi-apei-remove-arch_apei_flush_tlb_one.patch b/queue-4.9/acpi-apei-remove-arch_apei_flush_tlb_one.patch new file mode 100644 index 00000000000..98180701aec --- /dev/null +++ b/queue-4.9/acpi-apei-remove-arch_apei_flush_tlb_one.patch @@ -0,0 +1,44 @@ +From 4a75aeacda3c2455954596593d89187df5420d0a Mon Sep 17 00:00:00 2001 +From: James Morse +Date: Mon, 6 Nov 2017 18:44:27 +0000 +Subject: ACPI / APEI: Remove arch_apei_flush_tlb_one() + +From: James Morse + +commit 4a75aeacda3c2455954596593d89187df5420d0a upstream. + +Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on +__set_pte_vaddr() to do the invalidation when called from clear_fixmap() +Remove arch_apei_flush_tlb_one(). + +Signed-off-by: James Morse +Reviewed-by: Borislav Petkov +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/acpi/apei.c | 5 ----- + include/acpi/apei.h | 1 - + 2 files changed, 6 deletions(-) + +--- a/arch/x86/kernel/acpi/apei.c ++++ b/arch/x86/kernel/acpi/apei.c +@@ -55,8 +55,3 @@ void arch_apei_report_mem_error(int sev, + apei_mce_report_mem_error(sev, mem_err); + #endif + } +- +-void arch_apei_flush_tlb_one(unsigned long addr) +-{ +- __flush_tlb_one(addr); +-} +--- a/include/acpi/apei.h ++++ b/include/acpi/apei.h +@@ -44,7 +44,6 @@ int erst_clear(u64 record_id); + + int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, void *data); + void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err); +-void arch_apei_flush_tlb_one(unsigned long addr); + + #endif + #endif diff --git a/queue-4.9/acpi-ec-fix-regression-related-to-triggering-source-of-ec-event-handling.patch b/queue-4.9/acpi-ec-fix-regression-related-to-triggering-source-of-ec-event-handling.patch new file mode 100644 index 00000000000..126c2d24636 --- /dev/null +++ b/queue-4.9/acpi-ec-fix-regression-related-to-triggering-source-of-ec-event-handling.patch @@ -0,0 +1,78 @@ +From 53c5eaabaea9a1b7a96f95ccc486d2ad721d95bb Mon Sep 17 00:00:00 2001 +From: Lv Zheng +Date: Tue, 26 Sep 2017 16:54:03 +0800 +Subject: ACPI / EC: Fix regression related to triggering source of EC event handling + +From: Lv Zheng + +commit 53c5eaabaea9a1b7a96f95ccc486d2ad721d95bb upstream. + +Originally the Samsung quirks removed by commit 4c237371 can be covered +by commit e923e8e7 and ec_freeze_events=Y mode. But commit 9c40f956 +changed ec_freeze_events=Y back to N, making this problem re-surface. + +Actually, if commit e923e8e7 is robust enough, we can freely change +ec_freeze_events mode, so this patch fixes the issue by improving +commit e923e8e7. + +Related commits listed in the merged order: + + Commit: e923e8e79e18fd6be9162f1be6b99a002e9df2cb + Subject: ACPI / EC: Fix an issue that SCI_EVT cannot be detected + after event is enabled + + Commit: 4c237371f290d1ed3b2071dd43554362137b1cce + Subject: ACPI / EC: Remove old CLEAR_ON_RESUME quirk + + Commit: 9c40f956ce9b331493347d1b3cb7e384f7dc0581 + Subject: Revert "ACPI / EC: Enable event freeze mode..." to fix + a regression + +This patch not only fixes the reported post-resume EC event triggering +source issue, but also fixes an unreported similar issue related to the +driver bind by adding EC event triggering source in ec_install_handlers(). + +Fixes: e923e8e79e18 (ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled) +Fixes: 4c237371f290 (ACPI / EC: Remove old CLEAR_ON_RESUME quirk) +Fixes: 9c40f956ce9b (Revert "ACPI / EC: Enable event freeze mode..." to fix a regression) +Link: https://bugzilla.kernel.org/show_bug.cgi?id=196833 +Signed-off-by: Lv Zheng +Reported-by: Alistair Hamilton +Tested-by: Alistair Hamilton +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/ec.c | 12 +++++++----- + 1 file changed, 7 insertions(+), 5 deletions(-) + +--- a/drivers/acpi/ec.c ++++ b/drivers/acpi/ec.c +@@ -482,8 +482,11 @@ static inline void __acpi_ec_enable_even + { + if (!test_and_set_bit(EC_FLAGS_QUERY_ENABLED, &ec->flags)) + ec_log_drv("event unblocked"); +- if (!test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) +- advance_transaction(ec); ++ /* ++ * Unconditionally invoke this once after enabling the event ++ * handling mechanism to detect the pending events. ++ */ ++ advance_transaction(ec); + } + + static inline void __acpi_ec_disable_event(struct acpi_ec *ec) +@@ -1458,11 +1461,10 @@ static int ec_install_handlers(struct ac + if (test_bit(EC_FLAGS_STARTED, &ec->flags) && + ec->reference_count >= 1) + acpi_ec_enable_gpe(ec, true); +- +- /* EC is fully operational, allow queries */ +- acpi_ec_enable_event(ec); + } + } ++ /* EC is fully operational, allow queries */ ++ acpi_ec_enable_event(ec); + + return 0; + } diff --git a/queue-4.9/s390-disassembler-add-missing-end-marker-for-e7-table.patch b/queue-4.9/s390-disassembler-add-missing-end-marker-for-e7-table.patch new file mode 100644 index 00000000000..6ec55339c79 --- /dev/null +++ b/queue-4.9/s390-disassembler-add-missing-end-marker-for-e7-table.patch @@ -0,0 +1,38 @@ +From 5c50538752af7968f53924b22dede8ed4ce4cb3b Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Tue, 26 Sep 2017 09:16:48 +0200 +Subject: s390/disassembler: add missing end marker for e7 table + +From: Heiko Carstens + +commit 5c50538752af7968f53924b22dede8ed4ce4cb3b upstream. + +The e7 opcode table does not have an end marker. Hence when trying to +find an unknown e7 instruction the code will access memory behind the +table until it finds something that matches the opcode, or the kernel +crashes, whatever comes first. + +This affects not only the in-kernel disassembler but also uprobes and +kprobes which refuse to set a probe on unknown instructions, and +therefore search the opcode tables to figure out if instructions are +known or not. + +Fixes: 3585cb0280654 ("s390/disassembler: add vector instructions") +Signed-off-by: Heiko Carstens +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/dis.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/s390/kernel/dis.c ++++ b/arch/s390/kernel/dis.c +@@ -1548,6 +1548,7 @@ static struct s390_insn opcode_e7[] = { + { "vfsq", 0xce, INSTR_VRR_VV000MM }, + { "vfs", 0xe2, INSTR_VRR_VVV00MM }, + { "vftci", 0x4a, INSTR_VRI_VVIMM }, ++ { "", 0, INSTR_INVALID } + }; + + static struct s390_insn opcode_eb[] = { diff --git a/queue-4.9/s390-disassembler-increase-show_code-buffer-size.patch b/queue-4.9/s390-disassembler-increase-show_code-buffer-size.patch new file mode 100644 index 00000000000..76a4b606e3b --- /dev/null +++ b/queue-4.9/s390-disassembler-increase-show_code-buffer-size.patch @@ -0,0 +1,92 @@ +From b192571d1ae375e0bbe0aa3ccfa1a3c3704454b9 Mon Sep 17 00:00:00 2001 +From: Vasily Gorbik +Date: Wed, 15 Nov 2017 14:15:36 +0100 +Subject: s390/disassembler: increase show_code buffer size + +From: Vasily Gorbik + +commit b192571d1ae375e0bbe0aa3ccfa1a3c3704454b9 upstream. + +Current buffer size of 64 is too small. objdump shows that there are +instructions which would require up to 75 bytes buffer (with current +formating). 128 bytes "ought to be enough for anybody". + +Also replaces 8 spaces with a single tab to reduce the memory footprint. + +Fixes the following KASAN finding: + +BUG: KASAN: stack-out-of-bounds in number+0x3fe/0x538 +Write of size 1 at addr 000000005a4a75a0 by task bash/1282 + +CPU: 1 PID: 1282 Comm: bash Not tainted 4.14.0+ #215 +Hardware name: IBM 2964 N96 702 (z/VM 6.4.0) +Call Trace: +([<000000000011eeb6>] show_stack+0x56/0x88) + [<0000000000e1ce1a>] dump_stack+0x15a/0x1b0 + [<00000000004e2994>] print_address_description+0xf4/0x288 + [<00000000004e2cf2>] kasan_report+0x13a/0x230 + [<0000000000e38ae6>] number+0x3fe/0x538 + [<0000000000e3dfe4>] vsnprintf+0x194/0x948 + [<0000000000e3ea42>] sprintf+0xa2/0xb8 + [<00000000001198dc>] print_insn+0x374/0x500 + [<0000000000119346>] show_code+0x4ee/0x538 + [<000000000011f234>] show_registers+0x34c/0x388 + [<000000000011f2ae>] show_regs+0x3e/0xa8 + [<000000000011f502>] die+0x1ea/0x2e8 + [<0000000000138f0e>] do_no_context+0x106/0x168 + [<0000000000139a1a>] do_protection_exception+0x4da/0x7d0 + [<0000000000e55914>] pgm_check_handler+0x16c/0x1c0 + [<000000000090639e>] sysrq_handle_crash+0x46/0x58 +([<0000000000000007>] 0x7) + [<00000000009073fa>] __handle_sysrq+0x102/0x218 + [<0000000000907c06>] write_sysrq_trigger+0xd6/0x100 + [<000000000061d67a>] proc_reg_write+0xb2/0x128 + [<0000000000520be6>] __vfs_write+0xee/0x368 + [<0000000000521222>] vfs_write+0x21a/0x278 + [<000000000052156a>] SyS_write+0xda/0x178 + [<0000000000e555cc>] system_call+0xc4/0x270 + +The buggy address belongs to the page: +page:000003d1016929c0 count:0 mapcount:0 mapping: (null) index:0x0 +flags: 0x0() +raw: 0000000000000000 0000000000000000 0000000000000000 ffffffff00000000 +raw: 0000000000000100 0000000000000200 0000000000000000 0000000000000000 +page dumped because: kasan: bad access detected + +Memory state around the buggy address: + 000000005a4a7480: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 + 000000005a4a7500: 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00 00 +>000000005a4a7580: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 + ^ + 000000005a4a7600: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f8 + 000000005a4a7680: f2 f2 f2 f2 f2 f2 f8 f8 f2 f2 f3 f3 f3 f3 00 00 +================================================================== + +Signed-off-by: Vasily Gorbik +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/dis.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/s390/kernel/dis.c ++++ b/arch/s390/kernel/dis.c +@@ -1954,7 +1954,7 @@ void show_code(struct pt_regs *regs) + { + char *mode = user_mode(regs) ? "User" : "Krnl"; + unsigned char code[64]; +- char buffer[64], *ptr; ++ char buffer[128], *ptr; + mm_segment_t old_fs; + unsigned long addr; + int start, end, opsize, hops, i; +@@ -2017,7 +2017,7 @@ void show_code(struct pt_regs *regs) + start += opsize; + pr_cont("%s", buffer); + ptr = buffer; +- ptr += sprintf(ptr, "\n "); ++ ptr += sprintf(ptr, "\n\t "); + hops++; + } + pr_cont("\n"); diff --git a/queue-4.9/s390-fix-transactional-execution-control-register-handling.patch b/queue-4.9/s390-fix-transactional-execution-control-register-handling.patch new file mode 100644 index 00000000000..b390e0b3d42 --- /dev/null +++ b/queue-4.9/s390-fix-transactional-execution-control-register-handling.patch @@ -0,0 +1,108 @@ +From a1c5befc1c24eb9c1ee83f711e0f21ee79cbb556 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Thu, 9 Nov 2017 12:29:34 +0100 +Subject: s390: fix transactional execution control register handling +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Heiko Carstens + +commit a1c5befc1c24eb9c1ee83f711e0f21ee79cbb556 upstream. + +Dan Horák reported the following crash related to transactional execution: + +User process fault: interruption code 0013 ilc:3 in libpthread-2.26.so[3ff93c00000+1b000] +CPU: 2 PID: 1 Comm: /init Not tainted 4.13.4-300.fc27.s390x #1 +Hardware name: IBM 2827 H43 400 (z/VM 6.4.0) +task: 00000000fafc8000 task.stack: 00000000fafc4000 +User PSW : 0705200180000000 000003ff93c14e70 + R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 +User GPRS: 0000000000000077 000003ff00000000 000003ff93144d48 000003ff93144d5e + 0000000000000000 0000000000000002 0000000000000000 000003ff00000000 + 0000000000000000 0000000000000418 0000000000000000 000003ffcc9fe770 + 000003ff93d28f50 000003ff9310acf0 000003ff92b0319a 000003ffcc9fe6d0 +User Code: 000003ff93c14e62: 60e0b030 std %f14,48(%r11) + 000003ff93c14e66: 60f0b038 std %f15,56(%r11) + #000003ff93c14e6a: e5600000ff0e tbegin 0,65294 + >000003ff93c14e70: a7740006 brc 7,3ff93c14e7c + 000003ff93c14e74: a7080000 lhi %r0,0 + 000003ff93c14e78: a7f40023 brc 15,3ff93c14ebe + 000003ff93c14e7c: b2220000 ipm %r0 + 000003ff93c14e80: 8800001c srl %r0,28 + +There are several bugs with control register handling with respect to +transactional execution: + +- on task switch update_per_regs() is only called if the next task has + an mm (is not a kernel thread). This however is incorrect. This + breaks e.g. for user mode helper handling, where the kernel creates + a kernel thread and then execve's a user space program. Control + register contents related to transactional execution won't be + updated on execve. If the previous task ran with transactional + execution disabled then the new task will also run with + transactional execution disabled, which is incorrect. Therefore call + update_per_regs() unconditionally within switch_to(). + +- on startup the transactional execution facility is not enabled for + the idle thread. This is not really a bug, but an inconsistency to + other facilities. Therefore enable the facility if it is available. + +- on fork the new thread's per_flags field is not cleared. This means + that a child process inherits the PER_FLAG_NO_TE flag. This flag can + be set with a ptrace request to disable transactional execution for + the current process. It should not be inherited by new child + processes in order to be consistent with the handling of all other + PER related debugging options. Therefore clear the per_flags field in + copy_thread_tls(). + +Reported-and-tested-by: Dan Horák +Fixes: d35339a42dd1 ("s390: add support for transactional memory") +Cc: Martin Schwidefsky +Reviewed-by: Christian Borntraeger +Reviewed-by: Hendrik Brueckner +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/include/asm/switch_to.h | 2 +- + arch/s390/kernel/early.c | 4 +++- + arch/s390/kernel/process.c | 1 + + 3 files changed, 5 insertions(+), 2 deletions(-) + +--- a/arch/s390/include/asm/switch_to.h ++++ b/arch/s390/include/asm/switch_to.h +@@ -34,8 +34,8 @@ static inline void restore_access_regs(u + save_access_regs(&prev->thread.acrs[0]); \ + save_ri_cb(prev->thread.ri_cb); \ + } \ ++ update_cr_regs(next); \ + if (next->mm) { \ +- update_cr_regs(next); \ + set_cpu_flag(CIF_FPU); \ + restore_access_regs(&next->thread.acrs[0]); \ + restore_ri_cb(next->thread.ri_cb, prev->thread.ri_cb); \ +--- a/arch/s390/kernel/early.c ++++ b/arch/s390/kernel/early.c +@@ -345,8 +345,10 @@ static __init void detect_machine_facili + S390_lowcore.machine_flags |= MACHINE_FLAG_IDTE; + if (test_facility(40)) + S390_lowcore.machine_flags |= MACHINE_FLAG_LPP; +- if (test_facility(50) && test_facility(73)) ++ if (test_facility(50) && test_facility(73)) { + S390_lowcore.machine_flags |= MACHINE_FLAG_TE; ++ __ctl_set_bit(0, 55); ++ } + if (test_facility(51)) + S390_lowcore.machine_flags |= MACHINE_FLAG_TLB_LC; + if (test_facility(129)) { +--- a/arch/s390/kernel/process.c ++++ b/arch/s390/kernel/process.c +@@ -120,6 +120,7 @@ int copy_thread(unsigned long clone_flag + memset(&p->thread.per_user, 0, sizeof(p->thread.per_user)); + memset(&p->thread.per_event, 0, sizeof(p->thread.per_event)); + clear_tsk_thread_flag(p, TIF_SINGLE_STEP); ++ p->thread.per_flags = 0; + /* Initialize per thread user and system timer values */ + ti = task_thread_info(p); + ti->user_timer = 0; diff --git a/queue-4.9/s390-runtime-instrumention-fix-possible-memory-corruption.patch b/queue-4.9/s390-runtime-instrumention-fix-possible-memory-corruption.patch new file mode 100644 index 00000000000..378b2093bf2 --- /dev/null +++ b/queue-4.9/s390-runtime-instrumention-fix-possible-memory-corruption.patch @@ -0,0 +1,58 @@ +From d6e646ad7cfa7034d280459b2b2546288f247144 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Mon, 11 Sep 2017 11:24:22 +0200 +Subject: s390/runtime instrumention: fix possible memory corruption + +From: Heiko Carstens + +commit d6e646ad7cfa7034d280459b2b2546288f247144 upstream. + +For PREEMPT enabled kernels the runtime instrumentation (RI) code +contains a possible use-after-free bug. If a task that makes use of RI +exits, it will execute do_exit() while still enabled for preemption. + +That function will call exit_thread_runtime_instr() via +exit_thread(). If exit_thread_runtime_instr() gets preempted after the +RI control block of the task has been freed but before the pointer to +it is set to NULL, then save_ri_cb(), called from switch_to(), will +write to already freed memory. + +Avoid this and simply disable preemption while freeing the control +block and setting the pointer to NULL. + +Fixes: e4b8b3f33fca ("s390: add support for runtime instrumentation") +Reviewed-by: Christian Borntraeger +Signed-off-by: Heiko Carstens +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/runtime_instr.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/s390/kernel/runtime_instr.c ++++ b/arch/s390/kernel/runtime_instr.c +@@ -47,11 +47,13 @@ void exit_thread_runtime_instr(void) + { + struct task_struct *task = current; + ++ preempt_disable(); + if (!task->thread.ri_cb) + return; + disable_runtime_instr(); + kfree(task->thread.ri_cb); + task->thread.ri_cb = NULL; ++ preempt_enable(); + } + + SYSCALL_DEFINE1(s390_runtime_instr, int, command) +@@ -62,9 +64,7 @@ SYSCALL_DEFINE1(s390_runtime_instr, int, + return -EOPNOTSUPP; + + if (command == S390_RUNTIME_INSTR_STOP) { +- preempt_disable(); + exit_thread_runtime_instr(); +- preempt_enable(); + return 0; + } +