CVE-2016-1583 stack overflow via ecryptfs and /proc (rhbz 1344721 1344722)

ecryptfs-forbid-opening-files-without-mmap-handler.patch

@@ -0,0 +1,59 @@
+From 2f36db71009304b3f0b95afacd8eba1f9f046b87 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 1 Jun 2016 11:55:06 +0200
+Subject: [PATCH] ecryptfs: forbid opening files without mmap handler
+
+This prevents users from triggering a stack overflow through a recursive
+invocation of pagefault handling that involves mapping procfs files into
+virtual memory.
+
+Signed-off-by: Jann Horn <jannh@google.com>
+Acked-by: Tyler Hicks <tyhicks@canonical.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ fs/ecryptfs/kthread.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+diff --git a/fs/ecryptfs/kthread.c b/fs/ecryptfs/kthread.c
+index 866bb18efefe..e818f5ac7a26 100644
+--- a/fs/ecryptfs/kthread.c
++++ b/fs/ecryptfs/kthread.c
+@@ -25,6 +25,7 @@
+ #include <linux/slab.h>
+ #include <linux/wait.h>
+ #include <linux/mount.h>
++#include <linux/file.h>
+ #include "ecryptfs_kernel.h"
+ 
+ struct ecryptfs_open_req {
+@@ -147,7 +148,7 @@ int ecryptfs_privileged_open(struct file **lower_file,
+ 	flags |= IS_RDONLY(d_inode(lower_dentry)) ? O_RDONLY : O_RDWR;
+ 	(*lower_file) = dentry_open(&req.path, flags, cred);
+ 	if (!IS_ERR(*lower_file))
+-		goto out;
++		goto have_file;
+ 	if ((flags & O_ACCMODE) == O_RDONLY) {
+ 		rc = PTR_ERR((*lower_file));
+ 		goto out;
+@@ -165,8 +166,16 @@ int ecryptfs_privileged_open(struct file **lower_file,
+ 	mutex_unlock(&ecryptfs_kthread_ctl.mux);
+ 	wake_up(&ecryptfs_kthread_ctl.wait);
+ 	wait_for_completion(&req.done);
+-	if (IS_ERR(*lower_file))
++	if (IS_ERR(*lower_file)) {
+ 		rc = PTR_ERR(*lower_file);
++		goto out;
++	}
++have_file:
++	if ((*lower_file)->f_op->mmap == NULL) {
++		fput(*lower_file);
++		*lower_file = NULL;
++		rc = -EMEDIUMTYPE;
++	}
+ out:
+ 	return rc;
+ }
+-- 
+2.5.5
+

kernel.spec

@@ -628,6 +628,11 @@ Patch721: tipc-fix-an-infoleak-in-tipc_nl_compat_link_dump.patch
 #CVE-2016-5244 rhbz 1343338 1343337
 Patch722: rds-fix-an-infoleak-in-rds_inc_info_copy.txt
 
+#CVE-2016-1583 rhbz 1344721 1344722
+Patch723: proc-prevent-stacking-filesystems-on-top.patch
+Patch725: ecryptfs-forbid-opening-files-without-mmap-handler.patch
+Patch726: sched-panic-on-corrupted-stack-end.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -2153,6 +2158,9 @@ fi
 #
 # 
 %changelog
+* Mon Jun 13 2016 Josh Boyer <jwboyer@fedoraproject.org>
+- CVE-2016-1583 stack overflow via ecryptfs and /proc (rhbz 1344721 1344722)
+
 * Wed Jun 08 2016 Josh Boyer <jwboyer@fedoraproject.org>
 - Linux v4.6.2
 

proc-prevent-stacking-filesystems-on-top.patch

@@ -0,0 +1,41 @@
+From e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 1 Jun 2016 11:55:05 +0200
+Subject: [PATCH] proc: prevent stacking filesystems on top
+
+This prevents stacking filesystems (ecryptfs and overlayfs) from using
+procfs as lower filesystem.  There is too much magic going on inside
+procfs, and there is no good reason to stack stuff on top of procfs.
+
+(For example, procfs does access checks in VFS open handlers, and
+ecryptfs by design calls open handlers from a kernel thread that doesn't
+drop privileges or so.)
+
+Signed-off-by: Jann Horn <jannh@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ fs/proc/root.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/fs/proc/root.c b/fs/proc/root.c
+index 361ab4ee42fc..ec649c92d270 100644
+--- a/fs/proc/root.c
++++ b/fs/proc/root.c
+@@ -121,6 +121,13 @@ static struct dentry *proc_mount(struct file_system_type *fs_type,
+ 	if (IS_ERR(sb))
+ 		return ERR_CAST(sb);
+ 
++	/*
++	 * procfs isn't actually a stacking filesystem; however, there is
++	 * too much magic going on inside it to permit stacking things on
++	 * top of it
++	 */
++	sb->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH;
++
+ 	if (!proc_parse_options(options, ns)) {
+ 		deactivate_locked_super(sb);
+ 		return ERR_PTR(-EINVAL);
+-- 
+2.5.5
+

sched-panic-on-corrupted-stack-end.patch

@@ -0,0 +1,36 @@
+From 29d6455178a09e1dc340380c582b13356227e8df Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 1 Jun 2016 11:55:07 +0200
+Subject: [PATCH] sched: panic on corrupted stack end
+
+Until now, hitting this BUG_ON caused a recursive oops (because oops
+handling involves do_exit(), which calls into the scheduler, which in
+turn raises an oops), which caused stuff below the stack to be
+overwritten until a panic happened (e.g.  via an oops in interrupt
+context, caused by the overwritten CPU index in the thread_info).
+
+Just panic directly.
+
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ kernel/sched/core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/sched/core.c b/kernel/sched/core.c
+index d1f7149f8704..11546a6ed5df 100644
+--- a/kernel/sched/core.c
++++ b/kernel/sched/core.c
+@@ -3047,7 +3047,8 @@ static noinline void __schedule_bug(struct task_struct *prev)
+ static inline void schedule_debug(struct task_struct *prev)
+ {
+ #ifdef CONFIG_SCHED_STACK_END_CHECK
+-	BUG_ON(task_stack_end_corrupted(prev));
++	if (task_stack_end_corrupted(prev))
++		panic("corrupted stack end detected inside scheduler\n");
+ #endif
+ 
+ 	if (unlikely(in_atomic_preempt_off())) {
+-- 
+2.5.5
+