On Wed, Jun 12, 2019 at 11:43:13AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebigg...@google.com>
>
> sys_fsmount() needs to take a reference to the new mount when adding it
> to the anonymous mount namespace. Otherwise the filesystem can be
> unmounted while it's still in use, as found by syzkaller.
>
> Reported-by: Mark Rutland <mark.rutl...@arm.com>
> Reported-by: syzbot+99de05d099a170867...@syzkaller.appspotmail.com
> Reported-by: syzbot+7008b8b8ba7df475f...@syzkaller.appspotmail.com
> Fixes: 93766fbd2696 ("vfs: syscall: Add fsmount() to create a mount for a
> superblock")
> Signed-off-by: Eric Biggers <ebigg...@google.com>
With this patch applied, my reproducer from [1] no longer triggers the
issue. I polled /proc/meminfo, and don't see any leak. FWIW:
Tested-by: Mark Rutland <mark.rutl...@arm.com>
Thanks for fixing this!
Mark.
[1]
https://lore.kernel.org/lkml/20190605135401.gb30...@lakrids.cambridge.arm.com/
> ---
> fs/namespace.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index b26778bdc236e..5dc137a22d406 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -3445,6 +3445,7 @@ SYSCALL_DEFINE3(fsmount, int, fs_fd, unsigned int,
> flags,
> ns->root = mnt;
> ns->mounts = 1;
> list_add(&mnt->mnt_list, &ns->list);
> + mntget(newmount.mnt);
>
> /* Attach to an apparent O_PATH fd with a note that we need to unmount
> * it, not just simply put it.
> --
> 2.22.0.rc2.383.gf4fbbf30c2-goog
>
