Commit 156cacb1d0d36b0d0582d9e798e58e0044f516b3

Authored by Al Viro
1 parent fea7a08acb

do_add_mount()/umount -l races

normally we deal with lock_mount()/umount races by checking that
mountpoint to be is still in our namespace after lock_mount() has
been done.  However, do_add_mount() skips that check when called
with MNT_SHRINKABLE in flags (i.e. from finish_automount()).  The
reason is that ->mnt_ns may be a temporary namespace created exactly
to contain automounts a-la NFS4 referral handling.  It's not the
namespace of the caller, though, so check_mnt() would fail here.
We still need to check that ->mnt_ns is non-NULL in that case,
though.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Showing 1 changed file with 8 additions and 2 deletions Side-by-side Diff

... ... @@ -1886,8 +1886,14 @@
1886 1886 return err;
1887 1887  
1888 1888 err = -EINVAL;
1889   - if (!(mnt_flags & MNT_SHRINKABLE) && !check_mnt(real_mount(path->mnt)))
1890   - goto unlock;
  1889 + if (unlikely(!check_mnt(real_mount(path->mnt)))) {
  1890 + /* that's acceptable only for automounts done in private ns */
  1891 + if (!(mnt_flags & MNT_SHRINKABLE))
  1892 + goto unlock;
  1893 + /* ... and for those we'd better have mountpoint still alive */
  1894 + if (!real_mount(path->mnt)->mnt_ns)
  1895 + goto unlock;
  1896 + }
1891 1897  
1892 1898 /* Refuse the same filesystem on the same mount point */
1893 1899 err = -EBUSY;