From: Greg Kroah-Hartman Date: Sat, 25 Nov 2017 13:53:45 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v3.18.85~57 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ec1e26f8708da1f3e4f09677fa97c37dcac1afd2;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-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 acpi-pm-fix-acpi_pm_notifier_lock-vs-flush_workqueue-deadlock.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-guarded-storage-fix-possible-memory-corruption.patch s390-noexec-execute-kexec-datamover-without-dat.patch s390-runtime-instrumention-fix-possible-memory-corruption.patch --- diff --git a/queue-4.14/acpi-apei-remove-arch_apei_flush_tlb_one.patch b/queue-4.14/acpi-apei-remove-arch_apei_flush_tlb_one.patch new file mode 100644 index 00000000000..288cadcaa2f --- /dev/null +++ b/queue-4.14/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 +@@ -52,8 +52,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 +@@ -51,7 +51,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.14/acpi-ec-fix-regression-related-to-triggering-source-of-ec-event-handling.patch b/queue-4.14/acpi-ec-fix-regression-related-to-triggering-source-of-ec-event-handling.patch new file mode 100644 index 00000000000..2d331429a1c --- /dev/null +++ b/queue-4.14/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 +@@ -486,8 +486,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) +@@ -1456,11 +1459,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.14/acpi-pm-fix-acpi_pm_notifier_lock-vs-flush_workqueue-deadlock.patch b/queue-4.14/acpi-pm-fix-acpi_pm_notifier_lock-vs-flush_workqueue-deadlock.patch new file mode 100644 index 00000000000..d3321d90f05 --- /dev/null +++ b/queue-4.14/acpi-pm-fix-acpi_pm_notifier_lock-vs-flush_workqueue-deadlock.patch @@ -0,0 +1,197 @@ +From ff1656790b3a4caca94505c52fd0250f981ea187 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Tue, 7 Nov 2017 23:08:10 +0200 +Subject: ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit ff1656790b3a4caca94505c52fd0250f981ea187 upstream. + +acpi_remove_pm_notifier() ends up calling flush_workqueue() while +holding acpi_pm_notifier_lock, and that same lock is taken by +by the work via acpi_pm_notify_handler(). This can deadlock. + +To fix the problem let's split the single lock into two: one to +protect the dev->wakeup between the work vs. add/remove, and +another one to handle notifier installation vs. removal. + +After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work() +annotation" I was able to kill the machine (Intel Braswell) +very easily with 'powertop --auto-tune', runtime suspending i915, +and trying to wake it up via the USB keyboard. The cases when +it didn't die are presumably explained by lockdep getting disabled +by something else (cpu hotplug locking issues usually). + +Fortunately I still got a lockdep report over netconsole +(trickling in very slowly), even though the machine was +otherwise practically dead: + +[ 112.179806] ====================================================== +[ 114.670858] WARNING: possible circular locking dependency detected +[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted +[ 119.658101] ------------------------------------------------------ +[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command. +[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead +[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up +[ 121.313485] usb 1-6: USB disconnect, device number 3 +[ 121.313501] usb 1-6.2: USB disconnect, device number 4 +[ 134.747383] kworker/0:2/47 is trying to acquire lock: +[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [] acpi_pm_notify_handler+0x2f/0x80 +[ 139.721524] +[ 139.721524] but task is already holding lock: +[ 144.672922] ((&dpc->work)){+.+.}, at: [] process_one_work+0x160/0x720 +[ 147.184450] +[ 147.184450] which lock already depends on the new lock. +[ 147.184450] +[ 154.604711] +[ 154.604711] the existing dependency chain (in reverse order) is: +[ 159.447888] +[ 159.447888] -> #2 ((&dpc->work)){+.+.}: +[ 164.183486] __lock_acquire+0x1255/0x13f0 +[ 166.504313] lock_acquire+0xb5/0x210 +[ 168.778973] process_one_work+0x1b9/0x720 +[ 171.030316] worker_thread+0x4c/0x440 +[ 173.257184] kthread+0x154/0x190 +[ 175.456143] ret_from_fork+0x27/0x40 +[ 177.624348] +[ 177.624348] -> #1 ("kacpi_notify"){+.+.}: +[ 181.850351] __lock_acquire+0x1255/0x13f0 +[ 183.941695] lock_acquire+0xb5/0x210 +[ 186.046115] flush_workqueue+0xdd/0x510 +[ 190.408153] acpi_os_wait_events_complete+0x31/0x40 +[ 192.625303] acpi_remove_notify_handler+0x133/0x188 +[ 194.820829] acpi_remove_pm_notifier+0x56/0x90 +[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0 +[ 199.145866] dev_pm_domain_detach+0x27/0x30 +[ 201.285614] i2c_device_probe+0x100/0x210 +[ 203.411118] driver_probe_device+0x23e/0x310 +[ 205.522425] __driver_attach+0xa3/0xb0 +[ 207.634268] bus_for_each_dev+0x69/0xa0 +[ 209.714797] driver_attach+0x1e/0x20 +[ 211.778258] bus_add_driver+0x1bc/0x230 +[ 213.837162] driver_register+0x60/0xe0 +[ 215.868162] i2c_register_driver+0x42/0x70 +[ 217.869551] 0xffffffffa0172017 +[ 219.863009] do_one_initcall+0x45/0x170 +[ 221.843863] do_init_module+0x5f/0x204 +[ 223.817915] load_module+0x225b/0x29b0 +[ 225.757234] SyS_finit_module+0xc6/0xd0 +[ 227.661851] do_syscall_64+0x5c/0x120 +[ 229.536819] return_from_SYSCALL_64+0x0/0x7a +[ 231.392444] +[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}: +[ 235.124914] check_prev_add+0x44e/0x8a0 +[ 237.024795] __lock_acquire+0x1255/0x13f0 +[ 238.937351] lock_acquire+0xb5/0x210 +[ 240.840799] __mutex_lock+0x75/0x940 +[ 242.709517] mutex_lock_nested+0x1c/0x20 +[ 244.551478] acpi_pm_notify_handler+0x2f/0x80 +[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c +[ 248.194412] acpi_os_execute_deferred+0x14/0x30 +[ 250.003925] process_one_work+0x1ec/0x720 +[ 251.803191] worker_thread+0x4c/0x440 +[ 253.605307] kthread+0x154/0x190 +[ 255.387498] ret_from_fork+0x27/0x40 +[ 257.153175] +[ 257.153175] other info that might help us debug this: +[ 257.153175] +[ 262.324392] Chain exists of: +[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work) +[ 262.324392] +[ 267.391997] Possible unsafe locking scenario: +[ 267.391997] +[ 270.758262] CPU0 CPU1 +[ 272.431713] ---- ---- +[ 274.060756] lock((&dpc->work)); +[ 275.646532] lock("kacpi_notify"); +[ 277.260772] lock((&dpc->work)); +[ 278.839146] lock(acpi_pm_notifier_lock); +[ 280.391902] +[ 280.391902] *** DEADLOCK *** +[ 280.391902] +[ 284.986385] 2 locks held by kworker/0:2/47: +[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [] process_one_work+0x160/0x720 +[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [] process_one_work+0x160/0x720 +[ 289.727725] + +Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications) +Signed-off-by: Ville Syrjälä +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/device_pm.c | 21 ++++++++++++--------- + 1 file changed, 12 insertions(+), 9 deletions(-) + +--- a/drivers/acpi/device_pm.c ++++ b/drivers/acpi/device_pm.c +@@ -387,6 +387,7 @@ EXPORT_SYMBOL(acpi_bus_power_manageable) + + #ifdef CONFIG_PM + static DEFINE_MUTEX(acpi_pm_notifier_lock); ++static DEFINE_MUTEX(acpi_pm_notifier_install_lock); + + void acpi_pm_wakeup_event(struct device *dev) + { +@@ -443,24 +444,25 @@ acpi_status acpi_add_pm_notifier(struct + if (!dev && !func) + return AE_BAD_PARAMETER; + +- mutex_lock(&acpi_pm_notifier_lock); ++ mutex_lock(&acpi_pm_notifier_install_lock); + + if (adev->wakeup.flags.notifier_present) + goto out; + +- adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev)); +- adev->wakeup.context.dev = dev; +- adev->wakeup.context.func = func; +- + status = acpi_install_notify_handler(adev->handle, ACPI_SYSTEM_NOTIFY, + acpi_pm_notify_handler, NULL); + if (ACPI_FAILURE(status)) + goto out; + ++ mutex_lock(&acpi_pm_notifier_lock); ++ adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev)); ++ adev->wakeup.context.dev = dev; ++ adev->wakeup.context.func = func; + adev->wakeup.flags.notifier_present = true; ++ mutex_unlock(&acpi_pm_notifier_lock); + + out: +- mutex_unlock(&acpi_pm_notifier_lock); ++ mutex_unlock(&acpi_pm_notifier_install_lock); + return status; + } + +@@ -472,7 +474,7 @@ acpi_status acpi_remove_pm_notifier(stru + { + acpi_status status = AE_BAD_PARAMETER; + +- mutex_lock(&acpi_pm_notifier_lock); ++ mutex_lock(&acpi_pm_notifier_install_lock); + + if (!adev->wakeup.flags.notifier_present) + goto out; +@@ -483,14 +485,15 @@ acpi_status acpi_remove_pm_notifier(stru + if (ACPI_FAILURE(status)) + goto out; + ++ mutex_lock(&acpi_pm_notifier_lock); + adev->wakeup.context.func = NULL; + adev->wakeup.context.dev = NULL; + wakeup_source_unregister(adev->wakeup.ws); +- + adev->wakeup.flags.notifier_present = false; ++ mutex_unlock(&acpi_pm_notifier_lock); + + out: +- mutex_unlock(&acpi_pm_notifier_lock); ++ mutex_unlock(&acpi_pm_notifier_install_lock); + return status; + } + diff --git a/queue-4.14/s390-disassembler-add-missing-end-marker-for-e7-table.patch b/queue-4.14/s390-disassembler-add-missing-end-marker-for-e7-table.patch new file mode 100644 index 00000000000..6ec55339c79 --- /dev/null +++ b/queue-4.14/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.14/s390-disassembler-increase-show_code-buffer-size.patch b/queue-4.14/s390-disassembler-increase-show_code-buffer-size.patch new file mode 100644 index 00000000000..76a4b606e3b --- /dev/null +++ b/queue-4.14/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.14/s390-fix-transactional-execution-control-register-handling.patch b/queue-4.14/s390-fix-transactional-execution-control-register-handling.patch new file mode 100644 index 00000000000..434e0af59b2 --- /dev/null +++ b/queue-4.14/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 +@@ -37,8 +37,8 @@ static inline void restore_access_regs(u + save_ri_cb(prev->thread.ri_cb); \ + save_gs_cb(prev->thread.gs_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 +@@ -375,8 +375,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 +@@ -100,6 +100,7 @@ int copy_thread_tls(unsigned long clone_ + 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 */ + p->thread.user_timer = 0; + p->thread.guest_timer = 0; diff --git a/queue-4.14/s390-guarded-storage-fix-possible-memory-corruption.patch b/queue-4.14/s390-guarded-storage-fix-possible-memory-corruption.patch new file mode 100644 index 00000000000..67ba8ef11cf --- /dev/null +++ b/queue-4.14/s390-guarded-storage-fix-possible-memory-corruption.patch @@ -0,0 +1,46 @@ +From fa1edf3f63c05ca8eacafcd7048ed91e5360f1a8 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Mon, 11 Sep 2017 11:24:22 +0200 +Subject: s390/guarded storage: fix possible memory corruption + +From: Heiko Carstens + +commit fa1edf3f63c05ca8eacafcd7048ed91e5360f1a8 upstream. + +For PREEMPT enabled kernels the guarded storage (GS) code contains a +possible use-after-free bug. If a task that makes use of GS 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_gs() gets preempted after the GS control block of the +task has been freed but before the pointer to it is set to NULL, then +save_gs_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: 916cda1aa1b4 ("s390: add a system call for guarded storage") +Reviewed-by: Christian Borntraeger +Signed-off-by: Heiko Carstens +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/guarded_storage.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/s390/kernel/guarded_storage.c ++++ b/arch/s390/kernel/guarded_storage.c +@@ -14,9 +14,11 @@ + + void exit_thread_gs(void) + { ++ preempt_disable(); + kfree(current->thread.gs_cb); + kfree(current->thread.gs_bc_cb); + current->thread.gs_cb = current->thread.gs_bc_cb = NULL; ++ preempt_enable(); + } + + static int gs_enable(void) diff --git a/queue-4.14/s390-noexec-execute-kexec-datamover-without-dat.patch b/queue-4.14/s390-noexec-execute-kexec-datamover-without-dat.patch new file mode 100644 index 00000000000..be78c92cd26 --- /dev/null +++ b/queue-4.14/s390-noexec-execute-kexec-datamover-without-dat.patch @@ -0,0 +1,66 @@ +From d0e810eeb3d326978f248b8f0233a2f30f58c72d Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Thu, 9 Nov 2017 23:00:14 +0100 +Subject: s390/noexec: execute kexec datamover without DAT + +From: Heiko Carstens + +commit d0e810eeb3d326978f248b8f0233a2f30f58c72d upstream. + +Rebooting into a new kernel with kexec fails (system dies) if tried on +a machine that has no-execute support. Reason for this is that the so +called datamover code gets executed with DAT on (MMU is active) and +the page that contains the datamover is marked as non-executable. +Therefore when branching into the datamover an unexpected program +check happens and afterwards the machine is dead. + +This can be simply avoided by disabling DAT, which also disables any +no-execute checks, just before the datamover gets executed. + +In fact the first thing done by the datamover is to disable DAT. The +code in the datamover that disables DAT can be removed as well. + +Thanks to Michael Holzheu and Gerald Schaefer for tracking this down. + +Reviewed-by: Michael Holzheu +Reviewed-by: Philipp Rudo +Cc: Gerald Schaefer +Cc: Martin Schwidefsky +Fixes: 57d7f939e7bd ("s390: add no-execute support") +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/machine_kexec.c | 1 + + arch/s390/kernel/relocate_kernel.S | 3 --- + 2 files changed, 1 insertion(+), 3 deletions(-) + +--- a/arch/s390/kernel/machine_kexec.c ++++ b/arch/s390/kernel/machine_kexec.c +@@ -269,6 +269,7 @@ static void __do_machine_kexec(void *dat + s390_reset_system(); + data_mover = (relocate_kernel_t) page_to_phys(image->control_code_page); + ++ __arch_local_irq_stnsm(0xfb); /* disable DAT - avoid no-execute */ + /* Call the moving routine */ + (*data_mover)(&image->head, image->start); + +--- a/arch/s390/kernel/relocate_kernel.S ++++ b/arch/s390/kernel/relocate_kernel.S +@@ -29,7 +29,6 @@ + ENTRY(relocate_kernel) + basr %r13,0 # base address + .base: +- stnsm sys_msk-.base(%r13),0xfb # disable DAT + stctg %c0,%c15,ctlregs-.base(%r13) + stmg %r0,%r15,gprregs-.base(%r13) + lghi %r0,3 +@@ -103,8 +102,6 @@ ENTRY(relocate_kernel) + .align 8 + load_psw: + .long 0x00080000,0x80000000 +- sys_msk: +- .quad 0 + ctlregs: + .rept 16 + .quad 0 diff --git a/queue-4.14/s390-runtime-instrumention-fix-possible-memory-corruption.patch b/queue-4.14/s390-runtime-instrumention-fix-possible-memory-corruption.patch new file mode 100644 index 00000000000..c6656e7c534 --- /dev/null +++ b/queue-4.14/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 +@@ -50,11 +50,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) +@@ -65,9 +67,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; + } +