CVE-2014-7970 VFS: DoS with USER_NS (rhbz 1151095 1151484)
This commit is contained in:
parent
deaf6ef52a
commit
5c73e34a13
|
@ -753,6 +753,9 @@ Patch25109: revert-input-wacom-testing-result-shows-get_report-is-unnecessary.pa
|
|||
Patch25110: 0001-ideapad-laptop-Blacklist-rfkill-control-on-the-Lenov.patch
|
||||
Patch25111: 0002-ideapad-laptop-Change-Lenovo-Yoga-2-series-rfkill-ha.patch
|
||||
|
||||
#CVE-2014-7970 rhbz 1151095 1151484
|
||||
Patch26032: mnt-Prevent-pivot_root-from-creating-a-loop-in-the-m.patch
|
||||
|
||||
# END OF PATCH DEFINITIONS
|
||||
|
||||
%endif
|
||||
|
@ -1448,6 +1451,9 @@ ApplyPatch revert-input-wacom-testing-result-shows-get_report-is-unnecessary.pat
|
|||
ApplyPatch 0001-ideapad-laptop-Blacklist-rfkill-control-on-the-Lenov.patch
|
||||
ApplyPatch 0002-ideapad-laptop-Change-Lenovo-Yoga-2-series-rfkill-ha.patch
|
||||
|
||||
#CVE-2014-7970 rhbz 1151095 1151484
|
||||
ApplyPatch mnt-Prevent-pivot_root-from-creating-a-loop-in-the-m.patch
|
||||
|
||||
# END OF PATCH APPLICATIONS
|
||||
|
||||
%endif
|
||||
|
@ -2260,6 +2266,9 @@ fi
|
|||
# and build.
|
||||
|
||||
%changelog
|
||||
* Fri Oct 10 2014 Josh Boyer <jwboyer@fedoraproject.org>
|
||||
- CVE-2014-7970 VFS: DoS with USER_NS (rhbz 1151095 1151484)
|
||||
|
||||
* Thu Oct 09 2014 Justin M. Forbes <jforbes@fedoraproject.org> - 3.14.21-100
|
||||
- Linux v3.14.21
|
||||
|
||||
|
|
|
@ -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
|
||||
|
Loading…
Reference in New Issue