linux-toradex.git/fs/namespace.c, branch v3.18.4

umount: Disallow unprivileged mount force

2015-01-08T18:30:24+00:00

commit b2f5d4dc38e034eecb7987e513255265ff9aa1cf upstream.

Forced unmount affects not just the mount namespace but the underlying
superblock as well.  Restrict forced unmount to the global root user
for now.  Otherwise it becomes possible a user in a less privileged
mount namespace to force the shutdown of a superblock of a filesystem
in a more privileged mount namespace, allowing a DOS attack on root.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman

mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

2015-01-08T18:30:24+00:00

commit 3e1866410f11356a9fd869beb3e95983dc79c067 upstream.

Now that remount is properly enforcing the rule that you can't remove
nodev at least sandstorm.io is breaking when performing a remount.

It turns out that there is an easy intuitive solution implicitly
add nodev on remount when nodev was implicitly added on mount.

Tested-by: Cedric Bosdonnat 
Tested-by: Richard Weinberger 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman

mnt: Fix a memory stomp in umount

2015-01-08T18:30:24+00:00

commit c297abfdf15b4480704d6b566ca5ca9438b12456 upstream.

While reviewing the code of umount_tree I realized that when we append
to a preexisting unmounted list we do not change pprev of the former
first item in the list.

Which means later in namespace_unlock hlist_del_init(&mnt->mnt_hash) on
the former first item of the list will stomp unmounted.first leaving
it set to some random mount point which we are likely to free soon.

This isn't likely to hit, but if it does I don't know how anyone could
track it down.

[ This happened because we don't have all the same operations for
  hlist's as we do for normal doubly-linked lists. In particular,
  list_splice() is easy on our standard doubly-linked lists, while
  hlist_splice() doesn't exist and needs both start/end entries of the
  hlist.  And commit 38129a13e6e7 incorrectly open-coded that missing
  hlist_splice().

  We should think about making these kinds of "mindless" conversions
  easier to get right by adding the missing hlist helpers   - Linus ]

Fixes: 38129a13e6e71f666e0468e99fdd932a687b4d7e switch mnt_hash to hlist
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vfs: introduce clone_private_mount()

2014-10-23T22:14:36+00:00

Overlayfs needs a private clone of the mount, so create a function for
this and export to modules.

Signed-off-by: Miklos Szeredi

Merge branch 'CVE-2014-7970' of git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux

2014-10-15T04:43:27+00:00

Pull pivot_root() fix from Andy Lutomirski.

Prevent a leak of unreachable mounts.

* 'CVE-2014-7970' of git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux:
  mnt: Prevent pivot_root from creating a loop in the mount tree

mnt: Prevent pivot_root from creating a loop in the mount tree

2014-10-14T21:27:19+00:00

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.

[Added stable cc.  Fixes CVE-2014-7970.  --Andy]

Cc: stable@vger.kernel.org
Reported-by: Andy Lutomirski 
Reviewed-by: Andy Lutomirski 
Link: http://lkml.kernel.org/r/87bnpmihks.fsf@x220.int.ebiederm.org
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Andy Lutomirski

Merge branch 'CVE-2014-7975' of git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux

2014-10-14T06:35:01+00:00

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

vfs: move getname() from callers to do_mount()

2014-10-09T06:39:16+00:00

It would make more sense to pass char __user * instead of
char * in callers of do_mount() and do getname() inside do_mount().

Suggested-by: Al Viro 
Signed-off-by: Seunghun Lee 
Signed-off-by: Al Viro

fs: namespace: suppress 'may be used uninitialized' warnings

2014-10-09T06:39:10+00:00

The gcc version 4.9.1 compiler complains Even though it isn't possible for
these variables to not get initialized before they are used.

fs/namespace.c: In function ‘SyS_mount’:
fs/namespace.c:2720:8: warning: ‘kernel_dev’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags,
        ^
fs/namespace.c:2699:8: note: ‘kernel_dev’ was declared here
  char *kernel_dev;
        ^
fs/namespace.c:2720:8: warning: ‘kernel_type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags,
        ^
fs/namespace.c:2697:8: note: ‘kernel_type’ was declared here
  char *kernel_type;
        ^

Fix the warnings by simplifying copy_mount_string() as suggested by Al Viro.

Cc: Alexander Viro 
Signed-off-by: Tim Gardner 
Signed-off-by: Al Viro

vfs: Add a function to lazily unmount all mounts from any dentry.

2014-10-09T06:38:55+00:00

The new function detach_mounts comes in two pieces.  The first piece
is a static inline test of d_mounpoint that returns immediately
without taking any locks if d_mounpoint is not set.  In the common
case when mountpoints are absent this allows the vfs to continue
running with it's same cacheline foot print.

The second piece of detach_mounts __detach_mounts actually does the
work and it assumes that a mountpoint is present so it is slow and
takes namespace_sem for write, and then locks the mount hash (aka
mount_lock) after a struct mountpoint has been found.

With those two locks held each entry on the list of mounts on a
mountpoint is selected and lazily unmounted until all of the mount
have been lazily unmounted.

v7: Wrote a proper change description and removed the changelog
    documenting deleted wrong turns.

Signed-off-by: Eric W. Biederman 
Signed-off-by: Al Viro