From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Michal Hocko <mhocko@suse.cz>, Sergey Dyasly <dserrg@gmail.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/4] proc: first_tid: fix the potential use-after-free
Date: Mon, 3 Jun 2013 21:06:58 +0200 [thread overview]
Message-ID: <20130603190658.GA11500@redhat.com> (raw)
In-Reply-To: <20130603190640.GA11481@redhat.com>
proc_task_readdir() verifies that the result of get_proc_task()
is pid_alive() and thus its ->group_leader is fine too. However
this is not necessarily true after rcu_read_unlock(), we need
to recheck this again after first_tid() does rcu_read_lock().
Otherwise leader->thread_group.next (used by next_thread()) can
be invalid if the rcu grace period expires in between.
The race is subtle and unlikely, but still it is possible afaics.
To simplify lets ignore the "likely" case when tid != 0, f_version
can be cleared by proc_task_operations->llseek().
Suppose we have a main thread M and its subthread T. Suppose that
f_pos == 3, iow first_tid() should return T. Now suppose that the
following happens between rcu_read_unlock() and rcu_read_lock():
1. T execs and becomes the new leader. This removes M from
->thread_group but next_thread(M) is still T.
2. T creates another thread X which does exec as well, T
goes away.
3. X creates another subthread, this increments nr_threads.
4. first_tid() does next_thread(M) and returns the already
dead T.
Note also that we need 2. and 3. only because of get_nr_threads()
check, and this check was supposed to be optimization only.
Note: I think that proc_task_readdir/first_tid interaction can be
simplified, but this needs another patch. proc_task_readdir() should
not play with ->group_leader at all. See the next patches.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
fs/proc/base.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index dd51e50..daf41dc 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -3190,6 +3190,9 @@ static struct task_struct *first_tid(struct task_struct *leader,
pos = NULL;
if (nr && nr >= get_nr_threads(leader))
goto out;
+ /* It could be unhashed before we take rcu lock */
+ if (!pid_alive(leader))
+ goto out;
/* If we haven't found our starting place yet start
* with the leader and walk nr threads forward.
--
1.5.5.1
next prev parent reply other threads:[~2013-06-03 19:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 19:06 [PATCH v2 0/4] proc: first_tid() fix/cleanup Oleg Nesterov
2013-06-03 19:06 ` Oleg Nesterov [this message]
2013-06-03 19:07 ` [PATCH v2 2/4] proc: change first_tid() to use while_each_thread() Oleg Nesterov
2013-06-03 19:07 ` [PATCH v2 3/4] proc: simplify proc_task_readdir/first_tid paths Oleg Nesterov
2013-06-03 22:06 ` Eric W. Biederman
2013-06-03 19:07 ` [PATCH v2 4/4] proc: avoid ->f_pos overflows in proc_task_readdir() paths Oleg Nesterov
2013-06-03 22:18 ` Eric W. Biederman
2013-06-04 17:14 ` Oleg Nesterov
2013-06-04 17:39 ` Al Viro
2013-06-04 19:57 ` Oleg Nesterov
2013-06-04 21:06 ` Al Viro
2013-06-04 0:58 ` Al Viro
2013-06-04 17:35 ` Oleg Nesterov
2013-06-04 17:32 ` [PATCH v2 0/4] proc: first_tid() fix/cleanup Oleg Nesterov
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=20130603190658.GA11500@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dserrg@gmail.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox