From: Giuseppe Scrivano <gscrivan@redhat.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>, alexander.deucher@amd.com,
        broonie@kernel.org, chris@chris-wilson.co.uk,
        David Miller <davem@davemloft.net>, deepa.kernel@gmail.com,
        Greg KH <gregkh@linuxfoundation.org>, luc.vanoostenryck@gmail.com,
        lucien xin <lucien.xin@gmail.com>, Ingo Molnar <mingo@kernel.org>,
        Neil Horman <nhorman@tuxdriver.com>, syzkaller-bugs@googlegroups.com,
        Vladislav Yasevich <vyasevich@gmail.com>
Subject: Re: [PATCH linux-next] mqueue: fix IPC namespace use-after-free
References: <20171219101440.19736-1-gscrivan@redhat.com>
        <20171219114819.GQ21978@ZenIV.linux.org.uk>
        <20171219153225.GA14771@ZenIV.linux.org.uk>
Date: Tue, 19 Dec 2017 17:59:32 +0100
In-Reply-To: <20171219153225.GA14771@ZenIV.linux.org.uk> (Al Viro's message of
        "Tue, 19 Dec 2017 15:32:25 +0000")
Message-ID: <874lomhcwb.fsf@redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2196
Lines: 64

Al Viro <viro@ZenIV.linux.org.uk> writes:

> On Tue, Dec 19, 2017 at 11:48:19AM +0000, Al Viro wrote:
>> On Tue, Dec 19, 2017 at 11:14:40AM +0100, Giuseppe Scrivano wrote:
>> > mqueue_evict_inode() doesn't access the ipc namespace if it was
>> > already freed.  It can happen if in a new IPC namespace the inode was
>> > created without a prior mq_open() which creates the vfsmount used to
>> > access the superblock from mq_clear_sbinfo().
>> > 
>> > Keep a direct pointer to the superblock used by the inodes so we can
>> > correctly reset the reference to the IPC namespace being destroyed.
>> > 
>> > Bug introduced with 9c583773d03633 ("ipc, mqueue: lazy call
>> > kern_mount_data in new namespaces")
>> 
>> And just what will happen in the same scenario if you mount the damn
>> thing in userland without ever calling mq_open(), touch a file there,
>> then unmount and then leave the ipc namespace?
>
> FWIW, the real solution would be to have userland mounts trigger the creation
> of internal one, same as mq_open() would.  Something along these lines
> (completely untested, on top of vfs.git#for-next).  Care to give it some
> beating?

thanks for the patch.  It seems to work after this minor fixup on top of
it:

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 30327e201571..636989a44fae 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -360,7 +360,7 @@ static struct vfsmount *mq_internal_mount(void)
 		spin_unlock(&mq_lock);
 		if (!IS_ERR(m))
 			kern_unmount(m);
-			return ns->mq_mnt;
+		return ns->mq_mnt;
 	}
 	if (!IS_ERR(m))
 		ns->mq_mnt = m;
@@ -1560,6 +1560,7 @@ static struct file_system_type mqueue_fs_type = {
 
 int mq_init_ns(struct ipc_namespace *ns)
 {
+	ns->mq_mnt           = NULL;
 	ns->mq_queues_count  = 0;
 	ns->mq_queues_max    = DFLT_QUEUESMAX;
 	ns->mq_msg_max       = DFLT_MSGMAX;


The only issue I've seen with my version is that if I do:

# unshare -im /bin/sh
# mount -t mqueue mqueue /dev/mqueue
# touch /dev/mqueue/foo
# umount /dev/mqueue
# mount -t mqueue mqueue /dev/mqueue

then /dev/mqueue/foo doesn't exist at this point.  Your patch does not
have this problem and /dev/mqueue/foo is again accessible after the
second mount.

Regards,
Giuseppe