diff options
| -rw-r--r-- | kernel.spec | 9 | ||||
| -rw-r--r-- | mnt-Prevent-pivot_root-from-creating-a-loop-in-the-m.patch | 44 |
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 + |