CVE-2014-7970 VFS: DoS with USER_NS (rhbz 1151095 1151484)

2 files changed, 53 insertions, 0 deletions

diff --git a/kernel.spec b/kernel.spec
index 884cdc288..8ef5cd268 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -614,6 +614,9 @@ Patch26030: GFS2-Make-rename-not-save-dirent-location.patch
 
 Patch26032: Revert-pinctrl-qcom-use-restart_notifier-mechanism-f.patch
 
+#CVE-2014-7970 rhbz 1151095 1151484
+Patch26033: mnt-Prevent-pivot_root-from-creating-a-loop-in-the-m.patch
+
 # git clone ssh://git.fedorahosted.org/git/kernel-arm64.git, git diff master...devel
 Patch30000: kernel-arm64.patch
 
@@ -1340,6 +1343,9 @@ ApplyPatch GFS2-Make-rename-not-save-dirent-location.patch
 
 ApplyPatch Revert-pinctrl-qcom-use-restart_notifier-mechanism-f.patch
 
+#CVE-2014-7970 rhbz 1151095 1151484
+ApplyPatch mnt-Prevent-pivot_root-from-creating-a-loop-in-the-m.patch
+
 %if 0%{?aarch64patches}
 ApplyPatch kernel-arm64.patch
 %ifnarch aarch64 # this is stupid, but i want to notice before secondary koji does.
@@ -2208,6 +2214,9 @@ fi
 #                                    ||----w |
 #                                    ||     ||
 %changelog
+* Fri Oct 10 2014 Josh Boyer <jwboyer@fedoraproject.org>
+- CVE-2014-7970 VFS: DoS with USER_NS (rhbz 1151095 1151484)
+
 * Fri Oct 10 2014 Josh Boyer <jwboyer@fedoraproject.org> - 3.18.0-0.rc0.git4.1
 - Linux v3.17-6136-gc798360cd143
 
diff --git a/mnt-Prevent-pivot_root-from-creating-a-loop-in-the-m.patch b/mnt-Prevent-pivot_root-from-creating-a-loop-in-the-m.patch
new file mode 100644
index 000000000..0faadaf55
--- /dev/null
+++ b/mnt-Prevent-pivot_root-from-creating-a-loop-in-the-m.patch
@@ -0,0 +1,44 @@
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Wed, 8 Oct 2014 10:42:27 -0700
+Subject: [PATCH] mnt: Prevent pivot_root from creating a loop in the mount
+ tree
+
+Andy Lutomirski recently demonstrated that when chroot is used to set
+the root path below the path for the new ``root'' passed to pivot_root
+the pivot_root system call succeeds and leaks mounts.
+
+In examining the code I see that starting with a new root that is
+below the current root in the mount tree will result in a loop in the
+mount tree after the mounts are detached and then reattached to one
+another.  Resulting in all kinds of ugliness including a leak of that
+mounts involved in the leak of the mount loop.
+
+Prevent this problem by ensuring that the new mount is reachable from
+the current root of the mount tree.
+
+Upstream-status: Submitted for 3.18
+Bugzilla: 1151095,1151484
+
+Reported-by: Andy Lutomirski <luto@amacapital.net>
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+---
+ fs/namespace.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/namespace.c b/fs/namespace.c
+index ef42d9bee212..74647c2fe69c 100644
+--- a/fs/namespace.c
++++ b/fs/namespace.c
+@@ -2820,6 +2820,9 @@ SYSCALL_DEFINE2(pivot_root, const char __user *, new_root,
+ 	/* make sure we can reach put_old from new_root */
+ 	if (!is_path_reachable(old_mnt, old.dentry, &new))
+ 		goto out4;
++	/* make certain new is below the root */
++	if (!is_path_reachable(new_mnt, new.dentry, &root))
++		goto out4;
+ 	root_mp->m_count++; /* pin it so it won't go away */
+ 	lock_mount_hash();
+ 	detach_mnt(new_mnt, &parent_path);
+-- 
+1.9.3
+