linux-kernel - Re: [PATCH] proc: s_fs_info may be NULL when proc_kill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Jun 2020 12:12:54 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Alexey Gladkov <gladkov.alexey@...il.com>
Cc:     syzbot <syzbot+4abac52934a48af5ff19@...kaller.appspotmail.com>,
        adobriyan@...il.com, keescook@...omium.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: [PATCH] proc: s_fs_info may be NULL when proc_kill_sb is called

Alexey Gladkov <gladkov.alexey@...il.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@...kaller.appspotmail.com
> Fixes: fa10fed30f25 ("proc: allow to mount many instances of proc in one pid namespace")
> Signed-off-by: Alexey Gladkov <gladkov.alexey@...il.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 = {