mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-08-26 10:49:33 +00:00
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
This commit is contained in:
commit
0ef3a56b1c
1 changed files with 2 additions and 0 deletions
|
@ -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;
|
||||
down_write(&sb->s_umount);
|
||||
if (!(sb->s_flags & MS_RDONLY))
|
||||
retval = do_remount_sb(sb, MS_RDONLY, NULL, 0);
|
||||
|
|
Loading…
Reference in a new issue