From: Greg Kroah-Hartman Date: Tue, 7 Aug 2018 13:50:18 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.17.14~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c118de8761fe6e571c95702d18008a825030eab9;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: fork-unconditionally-clear-stack-on-fork.patch kmemleak-clear-stale-pointers-from-task-stacks.patch --- diff --git a/queue-4.9/fork-unconditionally-clear-stack-on-fork.patch b/queue-4.9/fork-unconditionally-clear-stack-on-fork.patch new file mode 100644 index 00000000000..e868292f54d --- /dev/null +++ b/queue-4.9/fork-unconditionally-clear-stack-on-fork.patch @@ -0,0 +1,102 @@ +From e01e80634ecdde1dd113ac43b3adad21b47f3957 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Fri, 20 Apr 2018 14:55:31 -0700 +Subject: fork: unconditionally clear stack on fork + +From: Kees Cook + +commit e01e80634ecdde1dd113ac43b3adad21b47f3957 upstream. + +One of the classes of kernel stack content leaks[1] is exposing the +contents of prior heap or stack contents when a new process stack is +allocated. Normally, those stacks are not zeroed, and the old contents +remain in place. In the face of stack content exposure flaws, those +contents can leak to userspace. + +Fixing this will make the kernel no longer vulnerable to these flaws, as +the stack will be wiped each time a stack is assigned to a new process. +There's not a meaningful change in runtime performance; it almost looks +like it provides a benefit. + +Performing back-to-back kernel builds before: + Run times: 157.86 157.09 158.90 160.94 160.80 + Mean: 159.12 + Std Dev: 1.54 + +and after: + Run times: 159.31 157.34 156.71 158.15 160.81 + Mean: 158.46 + Std Dev: 1.46 + +Instead of making this a build or runtime config, Andy Lutomirski +recommended this just be enabled by default. + +[1] A noisy search for many kinds of stack content leaks can be seen here: +https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+kernel+stack+leak + +I did some more with perf and cycle counts on running 100,000 execs of +/bin/true. + +before: +Cycles: 218858861551 218853036130 214727610969 227656844122 224980542841 +Mean: 221015379122.60 +Std Dev: 4662486552.47 + +after: +Cycles: 213868945060 213119275204 211820169456 224426673259 225489986348 +Mean: 217745009865.40 +Std Dev: 5935559279.99 + +It continues to look like it's faster, though the deviation is rather +wide, but I'm not sure what I could do that would be less noisy. I'm +open to ideas! + +Link: http://lkml.kernel.org/r/20180221021659.GA37073@beast +Signed-off-by: Kees Cook +Acked-by: Michal Hocko +Reviewed-by: Andrew Morton +Cc: Andy Lutomirski +Cc: Laura Abbott +Cc: Rasmus Villemoes +Cc: Mel Gorman +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +[ Srivatsa: Backported to 4.9.y ] +Signed-off-by: Srivatsa S. Bhat +Reviewed-by: Srinidhi Rao +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/thread_info.h | 7 +------ + kernel/fork.c | 3 +-- + 2 files changed, 2 insertions(+), 8 deletions(-) + +--- a/include/linux/thread_info.h ++++ b/include/linux/thread_info.h +@@ -59,12 +59,7 @@ extern long do_no_restart_syscall(struct + + #ifdef __KERNEL__ + +-#if IS_ENABLED(CONFIG_DEBUG_STACK_USAGE) || IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) +-# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_NOTRACK | \ +- __GFP_ZERO) +-#else +-# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_NOTRACK) +-#endif ++#define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_NOTRACK | __GFP_ZERO) + + /* + * flag set/clear/test wrappers +--- a/kernel/fork.c ++++ b/kernel/fork.c +@@ -184,10 +184,9 @@ static unsigned long *alloc_thread_stack + continue; + this_cpu_write(cached_stacks[i], NULL); + +-#ifdef CONFIG_DEBUG_KMEMLEAK + /* Clear stale pointers from reused stack. */ + memset(s->addr, 0, THREAD_SIZE); +-#endif ++ + tsk->stack_vm_area = s; + local_irq_enable(); + return s->addr; diff --git a/queue-4.9/kmemleak-clear-stale-pointers-from-task-stacks.patch b/queue-4.9/kmemleak-clear-stale-pointers-from-task-stacks.patch new file mode 100644 index 00000000000..4ee67bb117b --- /dev/null +++ b/queue-4.9/kmemleak-clear-stale-pointers-from-task-stacks.patch @@ -0,0 +1,49 @@ +From ca182551857cc2c1e6a2b7f1e72090a137a15008 Mon Sep 17 00:00:00 2001 +From: Konstantin Khlebnikov +Date: Fri, 13 Oct 2017 15:58:22 -0700 +Subject: kmemleak: clear stale pointers from task stacks + +From: Konstantin Khlebnikov + +commit ca182551857cc2c1e6a2b7f1e72090a137a15008 upstream. + +Kmemleak considers any pointers on task stacks as references. This +patch clears newly allocated and reused vmap stacks. + +Link: http://lkml.kernel.org/r/150728990124.744199.8403409836394318684.stgit@buzz +Signed-off-by: Konstantin Khlebnikov +Acked-by: Catalin Marinas +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +[ Srivatsa: Backported to 4.9.y ] +Signed-off-by: Srivatsa S. Bhat +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/thread_info.h | 2 +- + kernel/fork.c | 4 ++++ + 2 files changed, 5 insertions(+), 1 deletion(-) + +--- a/include/linux/thread_info.h ++++ b/include/linux/thread_info.h +@@ -59,7 +59,7 @@ extern long do_no_restart_syscall(struct + + #ifdef __KERNEL__ + +-#ifdef CONFIG_DEBUG_STACK_USAGE ++#if IS_ENABLED(CONFIG_DEBUG_STACK_USAGE) || IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) + # define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_NOTRACK | \ + __GFP_ZERO) + #else +--- a/kernel/fork.c ++++ b/kernel/fork.c +@@ -184,6 +184,10 @@ static unsigned long *alloc_thread_stack + continue; + this_cpu_write(cached_stacks[i], NULL); + ++#ifdef CONFIG_DEBUG_KMEMLEAK ++ /* Clear stale pointers from reused stack. */ ++ memset(s->addr, 0, THREAD_SIZE); ++#endif + tsk->stack_vm_area = s; + local_irq_enable(); + return s->addr; diff --git a/queue-4.9/series b/queue-4.9/series index 01f1300fa0a..53b1054f4e2 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -11,3 +11,5 @@ ring_buffer-tracing-inherit-the-tracing-setting-to-next-ring-buffer.patch i2c-imx-fix-reinit_completion-use.patch btrfs-fix-file-data-corruption-after-cloning-a-range-and-fsync.patch tcp-add-tcp_ooo_try_coalesce-helper.patch +kmemleak-clear-stale-pointers-from-task-stacks.patch +fork-unconditionally-clear-stack-on-fork.patch