linux-kernel - Re: [PATCH] fs, ipc: Use an asynchronous version of kern

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAKUOC8U8=2oG0vGgjgY6uR3ezw62kR2TsKH1d2mey9j265tFFg@mail.gmail.com>
Date:   Wed, 13 Feb 2019 13:07:58 -0800
From:   Salman Qazi <sqazi@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Eric Biederman <ebiederm@...ssion.com>,
        Eric Dumazet <edumazet@...gle.com>,
        linux-fsdevel@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fs, ipc: Use an asynchronous version of kern_unmount in IPC

Do you have any additional concerns?

On Thu, Feb 7, 2019 at 10:43 AM Salman Qazi <sqazi@...gle.com> wrote:
>
> On Wed, Feb 6, 2019 at 8:14 PM Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > On Wed, Feb 06, 2019 at 11:53:54AM -0800, Salman Qazi wrote:
> >
> > > This patch solves the issue by removing synchronize_rcu from mq_put_mnt.
> > > This is done by implementing an asynchronous version of kern_unmount.
> > >
> > > Since mntput() sleeps, it needs to be deferred to a work queue.
> > >
> > > Additionally, the callers of mq_put_mnt appear to be safe having
> > > it behave asynchronously.  In particular, put_ipc_ns calls
> > > mq_clear_sbinfo which renders the inode inaccessible for the purposes of
> > > mqueue_create by making s_fs_info NULL.  This appears
> > > to be the thing that prevents access while free_ipc_ns is taking place.
> > > So, the unmount should be able to proceed lazily.
> >
> > Ugh...  I really doubt that it's correct.  The caller is
> >                 mq_put_mnt(ns);
> >                 free_ipc_ns(ns);
> > and we have
> > static void mqueue_evict_inode(struct inode *inode)
> > {
> >
> > ...
> >
> >         ipc_ns = get_ns_from_inode(inode);
> >
> > with
> >
> > static struct ipc_namespace *get_ns_from_inode(struct inode *inode)
> > {
> >         struct ipc_namespace *ns;
> >
> >         spin_lock(&mq_lock);
> >         ns = __get_ns_from_inode(inode);
> >         spin_unlock(&mq_lock);
> >         return ns;
> > }
> >
> > and
> >
> > static inline struct ipc_namespace *__get_ns_from_inode(struct inode *inode)
> > {
> >         return get_ipc_ns(inode->i_sb->s_fs_info);
> > }
> >
> > with ->s_fs_info being the ipc_namespace we are freeing after mq_put_ns()
> >
> > Are you saying that get_ipc_ns() after free_ipc_ns() is safe?  Because
> > ->evict_inode() *IS* called on umount.  What happens to your patch if
> > there was a regular file left on that filesystem?
> >
> > Smells like a memory corruptor...
>
> Actually, the full context in the caller is
>
>         if (refcount_dec_and_lock(&ns->count, &mq_lock)) {
>                 mq_clear_sbinfo(ns);
>                 spin_unlock(&mq_lock);
>                 mq_put_mnt(ns);
>                 free_ipc_ns(ns);
>         }
>
> And
>
> void mq_clear_sbinfo(struct ipc_namespace *ns)
> {
>         ns->mq_mnt->mnt_sb->s_fs_info = NULL;
> }
>
> Therefore, s_fs_info should be NULL before we proceed to unmount.  So,
> as far as I know, it should not be possible to find the ipc_namespace
> from the mount.