]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'CVE-2014-7975' of git://git.kernel.org/pub/scm/linux/kernel/git/luto...
authorLinus Torvalds <torvalds@linux-foundation.org>
Tue, 14 Oct 2014 06:35:01 +0000 (08:35 +0200)
committerLinus Torvalds <torvalds@linux-foundation.org>
Tue, 14 Oct 2014 06:35:01 +0000 (08:35 +0200)
commit963498ed218cf9edfbad2a70d3c8a83db8ef9372
tree268d48a67ffeab5f11ceb604f6a7c5205f6a47e4
parent39d7a3c386648b9fac379cd15eda2a631d7e6b9a
parenta83e1732da5302d7ba28030b5814dfa7e86dd4a4
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
fs/namespace.c