Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Alexey Gladkov <gladkov.alexey@gmail.com>
Cc:     syzbot <syzbot+4abac52934a48af5ff19@syzkaller.appspotmail.com>,
        adobriyan@gmail.com, keescook@chromium.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk
References: <0000000000002d7ca605a7b8b1c5@google.com>
        <20200610130422.1197386-1-gladkov.alexey@gmail.com>
Date:   Wed, 10 Jun 2020 12:12:54 -0500
In-Reply-To: <20200610130422.1197386-1-gladkov.alexey@gmail.com> (Alexey
        Gladkov's message of "Wed, 10 Jun 2020 15:04:22 +0200")
Message-ID: <87mu5azvxl.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH] proc: s_fs_info may be NULL when proc_kill_sb is called
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Alexey Gladkov <gladkov.alexey@gmail.com> writes:

> syzbot found that proc_fill_super() fails before filling up sb->s_fs_info,
> deactivate_locked_super() will be called and sb->s_fs_info will be NULL.
> The proc_kill_sb() does not expect fs_info to be NULL which is wrong.

For the case where s_fs_info is never allocated this looks correct.
That is because generic_shutdown_super has a special for !sb->s_root.

However for the existing cases I can't convince myself that it is safe
to change the order we free the pid namespace and free fs_info.

There is a lot of code that can run while generic_shutdown_super is
running and purging all of the inodes.  We have crazy things like
proc_flush_pid that might care, as well proc_evict_inode.

I haven't found anything that actually references fs_info or actually
depends on the pid namespace living longer than the proc inode but it
would be really easy to miss something.

Can you send a v2 version does not change the order things are freed in
for the case where we do allocate fs_info.  That will make it trivially
safe to apply.

Otherwise this looks like a very good patch.

Thank you,
Eric


> Link: https://lore.kernel.org/lkml/0000000000002d7ca605a7b8b1c5@google.com
> Reported-by: syzbot+4abac52934a48af5ff19@syzkaller.appspotmail.com
> Fixes: fa10fed30f25 ("proc: allow to mount many instances of proc in one pid namespace")
> Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
> ---
>  fs/proc/root.c | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/fs/proc/root.c b/fs/proc/root.c
> index ffebed1999e5..a715eb9f196a 100644
> --- a/fs/proc/root.c
> +++ b/fs/proc/root.c
> @@ -264,15 +264,18 @@ static void proc_kill_sb(struct super_block *sb)
>  {
>  	struct proc_fs_info *fs_info = proc_sb_info(sb);
>  
> -	if (fs_info->proc_self)
> -		dput(fs_info->proc_self);
> +	if (fs_info) {
> +		if (fs_info->proc_self)
> +			dput(fs_info->proc_self);
>  
> -	if (fs_info->proc_thread_self)
> -		dput(fs_info->proc_thread_self);
> +		if (fs_info->proc_thread_self)
> +			dput(fs_info->proc_thread_self);
> +
> +		put_pid_ns(fs_info->pid_ns);
> +		kfree(fs_info);
> +	}
>  
>  	kill_anon_super(sb);
> -	put_pid_ns(fs_info->pid_ns);
> -	kfree(fs_info);
>  }
>  
>  static struct file_system_type proc_fs_type = {