From: Greg Kroah-Hartman Date: Mon, 20 Mar 2017 17:33:53 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v4.4.56~2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=91ca0cf9016cfbda5e0d28ef8b173ed2c8da377b;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: futex-add-missing-error-handling-to-futex_requeue_pi.patch futex-fix-potential-use-after-free-in-futex_requeue_pi.patch x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch --- diff --git a/queue-4.4/futex-add-missing-error-handling-to-futex_requeue_pi.patch b/queue-4.4/futex-add-missing-error-handling-to-futex_requeue_pi.patch new file mode 100644 index 00000000000..79bee559c50 --- /dev/null +++ b/queue-4.4/futex-add-missing-error-handling-to-futex_requeue_pi.patch @@ -0,0 +1,42 @@ +From 9bbb25afeb182502ca4f2c4f3f88af0681b34cae Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Sat, 4 Mar 2017 10:27:19 +0100 +Subject: futex: Add missing error handling to FUTEX_REQUEUE_PI + +From: Peter Zijlstra + +commit 9bbb25afeb182502ca4f2c4f3f88af0681b34cae upstream. + +Thomas spotted that fixup_pi_state_owner() can return errors and we +fail to unlock the rt_mutex in that case. + +Reported-by: Thomas Gleixner +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Darren Hart +Cc: juri.lelli@arm.com +Cc: bigeasy@linutronix.de +Cc: xlpang@redhat.com +Cc: rostedt@goodmis.org +Cc: mathieu.desnoyers@efficios.com +Cc: jdesfossez@efficios.com +Cc: dvhart@infradead.org +Cc: bristot@redhat.com +Link: http://lkml.kernel.org/r/20170304093558.867401760@infradead.org +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -2773,6 +2773,8 @@ static int futex_wait_requeue_pi(u32 __u + if (q.pi_state && (q.pi_state->owner != current)) { + spin_lock(q.lock_ptr); + ret = fixup_pi_state_owner(uaddr2, &q, current); ++ if (ret && rt_mutex_owner(&q.pi_state->pi_mutex) == current) ++ rt_mutex_unlock(&q.pi_state->pi_mutex); + /* + * Drop the reference to the pi state which + * the requeue_pi() code acquired for us. diff --git a/queue-4.4/futex-fix-potential-use-after-free-in-futex_requeue_pi.patch b/queue-4.4/futex-fix-potential-use-after-free-in-futex_requeue_pi.patch new file mode 100644 index 00000000000..7c4e231c5d3 --- /dev/null +++ b/queue-4.4/futex-fix-potential-use-after-free-in-futex_requeue_pi.patch @@ -0,0 +1,85 @@ +From c236c8e95a3d395b0494e7108f0d41cf36ec107c Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Sat, 4 Mar 2017 10:27:18 +0100 +Subject: futex: Fix potential use-after-free in FUTEX_REQUEUE_PI + +From: Peter Zijlstra + +commit c236c8e95a3d395b0494e7108f0d41cf36ec107c upstream. + +While working on the futex code, I stumbled over this potential +use-after-free scenario. Dmitry triggered it later with syzkaller. + +pi_mutex is a pointer into pi_state, which we drop the reference on in +unqueue_me_pi(). So any access to that pointer after that is bad. + +Since other sites already do rt_mutex_unlock() with hb->lock held, see +for example futex_lock_pi(), simply move the unlock before +unqueue_me_pi(). + +Reported-by: Dmitry Vyukov +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Darren Hart +Cc: juri.lelli@arm.com +Cc: bigeasy@linutronix.de +Cc: xlpang@redhat.com +Cc: rostedt@goodmis.org +Cc: mathieu.desnoyers@efficios.com +Cc: jdesfossez@efficios.com +Cc: dvhart@infradead.org +Cc: bristot@redhat.com +Link: http://lkml.kernel.org/r/20170304093558.801744246@infradead.org +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 20 +++++++++++--------- + 1 file changed, 11 insertions(+), 9 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -2690,7 +2690,6 @@ static int futex_wait_requeue_pi(u32 __u + { + struct hrtimer_sleeper timeout, *to = NULL; + struct rt_mutex_waiter rt_waiter; +- struct rt_mutex *pi_mutex = NULL; + struct futex_hash_bucket *hb; + union futex_key key2 = FUTEX_KEY_INIT; + struct futex_q q = futex_q_init; +@@ -2782,6 +2781,8 @@ static int futex_wait_requeue_pi(u32 __u + spin_unlock(q.lock_ptr); + } + } else { ++ struct rt_mutex *pi_mutex; ++ + /* + * We have been woken up by futex_unlock_pi(), a timeout, or a + * signal. futex_unlock_pi() will not destroy the lock_ptr nor +@@ -2805,18 +2806,19 @@ static int futex_wait_requeue_pi(u32 __u + if (res) + ret = (res < 0) ? res : 0; + ++ /* ++ * If fixup_pi_state_owner() faulted and was unable to handle ++ * the fault, unlock the rt_mutex and return the fault to ++ * userspace. ++ */ ++ if (ret && rt_mutex_owner(pi_mutex) == current) ++ rt_mutex_unlock(pi_mutex); ++ + /* Unqueue and drop the lock. */ + unqueue_me_pi(&q); + } + +- /* +- * If fixup_pi_state_owner() faulted and was unable to handle the +- * fault, unlock the rt_mutex and return the fault to userspace. +- */ +- if (ret == -EFAULT) { +- if (pi_mutex && rt_mutex_owner(pi_mutex) == current) +- rt_mutex_unlock(pi_mutex); +- } else if (ret == -EINTR) { ++ if (ret == -EINTR) { + /* + * We've already been requeued, but cannot restart by calling + * futex_lock_pi() directly. We could restart this syscall, but diff --git a/queue-4.4/series b/queue-4.4/series index 1e86fbb11c8..703483ef560 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -22,3 +22,7 @@ dccp-fix-memory-leak-during-tear-down-of-unsuccessful-connection-request.patch net-sched-actions-decrement-module-reference-count-after-table-flush.patch fscrypt-fix-renaming-and-linking-special-files.patch fscrypto-lock-inode-while-setting-encryption-policy.patch +x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch +x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch +futex-fix-potential-use-after-free-in-futex_requeue_pi.patch +futex-add-missing-error-handling-to-futex_requeue_pi.patch diff --git a/queue-4.4/x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch b/queue-4.4/x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch new file mode 100644 index 00000000000..11a6d42106f --- /dev/null +++ b/queue-4.4/x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch @@ -0,0 +1,52 @@ +From be3606ff739d1c1be36389f8737c577ad87e1f57 Mon Sep 17 00:00:00 2001 +From: Andrey Ryabinin +Date: Mon, 13 Mar 2017 19:33:37 +0300 +Subject: x86/kasan: Fix boot with KASAN=y and PROFILE_ANNOTATED_BRANCHES=y + +From: Andrey Ryabinin + +commit be3606ff739d1c1be36389f8737c577ad87e1f57 upstream. + +The kernel doesn't boot with both PROFILE_ANNOTATED_BRANCHES=y and KASAN=y +options selected. With branch profiling enabled we end up calling +ftrace_likely_update() before kasan_early_init(). ftrace_likely_update() is +built with KASAN instrumentation, so calling it before kasan has been +initialized leads to crash. + +Use DISABLE_BRANCH_PROFILING define to make sure that we don't call +ftrace_likely_update() from early code before kasan_early_init(). + +Fixes: ef7f0d6a6ca8 ("x86_64: add KASan support") +Reported-by: Fengguang Wu +Signed-off-by: Andrey Ryabinin +Cc: kasan-dev@googlegroups.com +Cc: Alexander Potapenko +Cc: Andrew Morton +Cc: lkp@01.org +Cc: Dmitry Vyukov +Link: http://lkml.kernel.org/r/20170313163337.1704-1-aryabinin@virtuozzo.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/head64.c | 1 + + arch/x86/mm/kasan_init_64.c | 1 + + 2 files changed, 2 insertions(+) + +--- a/arch/x86/kernel/head64.c ++++ b/arch/x86/kernel/head64.c +@@ -4,6 +4,7 @@ + * Copyright (C) 2000 Andrea Arcangeli SuSE + */ + ++#define DISABLE_BRANCH_PROFILING + #include + #include + #include +--- a/arch/x86/mm/kasan_init_64.c ++++ b/arch/x86/mm/kasan_init_64.c +@@ -1,3 +1,4 @@ ++#define DISABLE_BRANCH_PROFILING + #define pr_fmt(fmt) "kasan: " fmt + #include + #include diff --git a/queue-4.4/x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch b/queue-4.4/x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch new file mode 100644 index 00000000000..db88c11a226 --- /dev/null +++ b/queue-4.4/x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch @@ -0,0 +1,48 @@ +From 5dc855d44c2ad960a86f593c60461f1ae1566b6d Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Thu, 16 Mar 2017 12:59:39 -0700 +Subject: x86/perf: Fix CR4.PCE propagation to use active_mm instead of mm + +From: Andy Lutomirski + +commit 5dc855d44c2ad960a86f593c60461f1ae1566b6d upstream. + +If one thread mmaps a perf event while another thread in the same mm +is in some context where active_mm != mm (which can happen in the +scheduler, for example), refresh_pce() would write the wrong value +to CR4.PCE. This broke some PAPI tests. + +Reported-and-tested-by: Vince Weaver +Signed-off-by: Andy Lutomirski +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Borislav Petkov +Cc: H. Peter Anvin +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Stephane Eranian +Cc: Thomas Gleixner +Cc: stable@vger.kernel.org +Fixes: 7911d3f7af14 ("perf/x86: Only allow rdpmc if a perf_event is mapped") +Link: http://lkml.kernel.org/r/0c5b38a76ea50e405f9abe07a13dfaef87c173a1.1489694270.git.luto@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/perf_event.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/cpu/perf_event.c ++++ b/arch/x86/kernel/cpu/perf_event.c +@@ -1996,8 +1996,8 @@ static int x86_pmu_event_init(struct per + + static void refresh_pce(void *ignored) + { +- if (current->mm) +- load_mm_cr4(current->mm); ++ if (current->active_mm) ++ load_mm_cr4(current->active_mm); + } + + static void x86_pmu_event_mapped(struct perf_event *event)