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
Subject: Re: [PATCH] proc: s_fs_info may be NULL when proc_kill_sb is called
Date: Wed, 10 Jun 2020 12:12:54 -0500 [thread overview]
Message-ID: <87mu5azvxl.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20200610130422.1197386-1-gladkov.alexey@gmail.com> (Alexey Gladkov's message of "Wed, 10 Jun 2020 15:04:22 +0200")
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 = {
next prev parent reply other threads:[~2020-06-10 17:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 10:56 general protection fault in proc_kill_sb syzbot
2020-06-10 11:23 ` Tetsuo Handa
2020-06-10 11:44 ` Alexey Gladkov
2020-06-10 13:04 ` [PATCH] proc: s_fs_info may be NULL when proc_kill_sb is called Alexey Gladkov
2020-06-10 17:12 ` Eric W. Biederman [this message]
2020-06-10 17:41 ` Al Viro
2020-06-10 18:35 ` [PATCH v2] " Alexey Gladkov
2020-06-10 20:17 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mu5azvxl.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=gladkov.alexey@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+4abac52934a48af5ff19@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.