Messages in this thread Patch in this message | | | From | Giuseppe Scrivano <> | Subject | Re: [PATCH linux-next] mqueue: fix IPC namespace use-after-free | Date | Tue, 19 Dec 2017 17:59:32 +0100 |
| |
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
| |