|author||Linus Torvalds <firstname.lastname@example.org>||2014-10-14 08:35:01 +0200|
|committer||Linus Torvalds <email@example.com>||2014-10-14 08:35:01 +0200|
Merge branch 'CVE-2014-7975' of git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux
Pull do_umount fix from Andy Lutomirski: "This fix really ought to be safe. Inside a mountns owned by a non-root user namespace, the namespace root almost always has MNT_LOCKED set (if it doesn't, then there's a bug, because rootfs could be exposed). In that case, calling umount on "/" will return -EINVAL with or without this patch. Outside a userns, this patch will have no effect. may_mount, required by umount, already checks ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN) so an additional capable(CAP_SYS_ADMIN) check will have no effect. That leaves anything that calls umount on "/" in a non-root userns while chrooted. This is the case that is currently broken (it remounts ro, which shouldn't be allowed) and that my patch changes to -EPERM. If anything relies on *that*, I'd be surprised" * 'CVE-2014-7975' of git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux: fs: Add a missing permission check to do_umount
Diffstat (limited to 'fs')
1 files changed, 2 insertions, 0 deletions
diff --git a/fs/namespace.c b/fs/namespace.c
index 348562f14e93..2651328d1790 100644
@@ -1439,6 +1439,8 @@ static int do_umount(struct mount *mnt, int flags)
* Special case for "unmounting" root ...
* we just try to remount it readonly.
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
if (!(sb->s_flags & MS_RDONLY))
retval = do_remount_sb(sb, MS_RDONLY, NULL, 0);