[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87vah2ftn8.fsf@redhat.com>
Date: Tue, 19 Dec 2017 19:40:43 +0100
From: Giuseppe Scrivano <gscrivan@...hat.com>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, alexander.deucher@....com,
broonie@...nel.org, chris@...is-wilson.co.uk,
David Miller <davem@...emloft.net>, deepa.kernel@...il.com,
Greg KH <gregkh@...uxfoundation.org>,
luc.vanoostenryck@...il.com, lucien xin <lucien.xin@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Neil Horman <nhorman@...driver.com>,
syzkaller-bugs@...glegroups.com,
Vladislav Yasevich <vyasevich@...il.com>
Subject: Re: [PATCH linux-next] mqueue: fix IPC namespace use-after-free
Giuseppe Scrivano <gscrivan@...hat.com> writes:
> 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.
although, how much is that of an issue? Is there any other way to delay
the cost of kern_mount_data()? Most containers have /dev/mqueue mounted
but it is not really going to be used.
Would it be possible somehow to postpone it until the first inode is
created?
Thanks,
Giuseppe
Powered by blists - more mailing lists