From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Aleksa Sarai <asarai@suse.com>,
Andy Lutomirski <luto@amacapital.net>,
Attila Fazekas <afazekas@redhat.com>, Jann Horn <jann@thejh.net>,
Kees Cook <keescook@chromium.org>,
Michal Hocko <mhocko@kernel.org>,
Ulrich Obergfell <uobergfe@redhat.com>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [RFC][PATCH] exec: Don't wait for ptraced threads to be reaped.
Date: Sat, 4 Mar 2017 18:03:13 +0100 [thread overview]
Message-ID: <20170304170312.GB13131@redhat.com> (raw)
In-Reply-To: <87lgsmunmj.fsf_-_@xmission.com>
On 03/03, Eric W. Biederman wrote:
>
> Ever since CLONE_THREAD support was added to the kernel it has been
> possible to dead-lock userspace by ptracing a process and not reaping
> it's child threads.
Hmm. I disagree... I do not think this is a bug. But lets discuss this
separately, perhaps I misunderstood you.
> With use of the cred_guard_mutex in proc the ways
> userspace can unknowningly trigger a dead-lock have grown.
I think this particular problem did not exist until cred_guard_mutex
was introduced. Debugger can obviously "delay" exec if it doesn't
reap a zombie sub-thread, but this is another thing and not a bug imo.
> Sovle this by modifying exec to only wait until all of the other
> threads are zombies, and not waiting until the other threads
> are reaped.
This patch looks wrong in many ways.
> @@ -1065,11 +1065,8 @@ static int de_thread(struct task_struct *tsk)
> }
>
> sig->group_exit_task = tsk;
> - sig->notify_count = zap_other_threads(tsk);
> - if (!thread_group_leader(tsk))
> - sig->notify_count--;
> -
> - while (sig->notify_count) {
> + zap_other_threads(tsk);
> + while (atomic_read(&sig->live) > 1) {
> __set_current_state(TASK_KILLABLE);
> spin_unlock_irq(lock);
> schedule();
Very nice. So de_thread() returns as soon as all other threads decrement
signal->live in do_exit(). Before they do, say, exit_mm(). This is already
wrong, for example this breaks OOM. Plus a lot more problems afaics, but
lets ignore this.
Note that de_thread() also unshares ->sighand before return. So in the
case of mt exec it will likely see oldsighand->count != 1 and alloc the
new sighand_struct and this breaks the locking.
Because the execing thread will use newsighand->siglock to protect its
signal_struct while the zombie threads will use oldsighand->siglock to
protect the same signal struct. Yes, tasklist_lock + the fact irq_disable
implies rcu_lock mostly save us but not entirely, say, a foreign process
doing __send_signal() can take the right or the wrong lock depending on
/dev/random.
> @@ -818,6 +808,8 @@ void __noreturn do_exit(long code)
> if (tsk->mm)
> setmax_mm_hiwater_rss(&tsk->signal->maxrss, tsk->mm);
> }
> + if ((group_left == 1) && tsk->signal->group_exit_task)
> + wake_up_process(tsk->signal->group_exit_task);
This is racy, but this is minor.
Oleg.
next prev parent reply other threads:[~2017-03-04 17:03 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170213141452.GA30203@redhat.com>
[not found] ` <20170224160354.GA845@redhat.com>
[not found] ` <87shmv6ufl.fsf@xmission.com>
[not found] ` <20170303173326.GA17899@redhat.com>
[not found] ` <20170303173326.GA17899-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-03 18:23 ` [PATCH 0/2] fix the traced mt-exec deadlock Eric W. Biederman
2017-03-03 18:59 ` Eric W. Biederman
[not found] ` <87d1dyw5iw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-03-03 20:06 ` Eric W. Biederman
[not found] ` <87tw7aunuh.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-03-03 20:11 ` [RFC][PATCH] exec: Don't wait for ptraced threads to be reaped Eric W. Biederman
2017-03-04 17:03 ` Oleg Nesterov [this message]
2017-03-30 8:07 ` Eric W. Biederman
[not found] ` <8760ir192p.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-01 5:11 ` [RFC][PATCH 0/2] exec: Fixing ptrace'd mulit-threaded hang Eric W. Biederman
[not found] ` <878tnkpv8h.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-01 5:14 ` [RFC][PATCH 1/2] sighand: Count each thread group once in sighand_struct Eric W. Biederman
2017-04-01 5:16 ` [RFC][PATCH 2/2] exec: If possible don't wait for ptraced threads to be reaped Eric W. Biederman
[not found] ` <87vaqooggs.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-02 15:35 ` Oleg Nesterov
[not found] ` <20170402153517.GA12637-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-02 18:53 ` Eric W. Biederman
[not found] ` <877f32k5ew.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-03 18:12 ` Oleg Nesterov
2017-04-03 21:04 ` Eric W. Biederman
2017-04-05 16:44 ` Oleg Nesterov
2017-04-02 15:38 ` [RFC][PATCH 0/2] exec: Fixing ptrace'd mulit-threaded hang Oleg Nesterov
2017-04-02 22:50 ` [RFC][PATCH v2 0/5] " Eric W. Biederman
[not found] ` <874ly6a0h1.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-02 22:51 ` [RFC][PATCH v2 1/5] ptrace: Don't wait in PTRACE_O_TRACEEXIT for exec or coredump Eric W. Biederman
2017-04-05 16:19 ` Oleg Nesterov
2017-04-02 22:51 ` [RFC][PATCH v2 2/5] sighand: Count each thread group once in sighand_struct Eric W. Biederman
2017-04-02 22:52 ` [RFC][PATCH v2 3/5] clone: Disallown CLONE_THREAD with a shared sighand_struct Eric W. Biederman
[not found] ` <87k2728lrp.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-05 16:24 ` Oleg Nesterov
2017-04-05 17:34 ` Eric W. Biederman
2017-04-05 18:11 ` Oleg Nesterov
2017-04-02 22:53 ` [RFC][PATCH v2 4/5] exec: If possible don't wait for ptraced threads to be reaped Eric W. Biederman
2017-04-05 16:15 ` Oleg Nesterov
2017-04-02 22:57 ` [RFC][PATCH v2 5/5] signal: Don't allow accessing signal_struct by old threads after exec Eric W. Biederman
[not found] ` <87zify76z9.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-05 16:18 ` Oleg Nesterov
[not found] ` <20170405161812.GD14536-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-05 18:16 ` Eric W. Biederman
[not found] ` <87zifu90to.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-06 15:48 ` Oleg Nesterov
2017-04-02 16:15 ` [RFC][PATCH] exec: Don't wait for ptraced threads to be reaped Oleg Nesterov
[not found] ` <20170402161518.GC12637-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-02 21:07 ` Eric W. Biederman
[not found] ` <87inmmbjsq.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-03 18:37 ` Oleg Nesterov
[not found] ` <20170403183728.GB31390-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-03 22:49 ` Eric W. Biederman
2017-04-03 22:49 ` scope of cred_guard_mutex Eric W. Biederman
2017-04-05 16:08 ` Oleg Nesterov
2017-04-05 16:11 ` Kees Cook
2017-04-05 17:53 ` Eric W. Biederman
2017-04-05 18:15 ` Oleg Nesterov
[not found] ` <87fuhpjeco.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-06 15:55 ` Oleg Nesterov
[not found] ` <20170406155540.GC7444-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-07 22:07 ` Kees Cook
2017-09-04 3:19 ` [RFC][PATCH] exec: Don't wait for ptraced threads to be reaped Robert O'Callahan
[not found] ` <87tw7axlr0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-03-04 16:54 ` [PATCH 0/2] fix the traced mt-exec deadlock 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=20170304170312.GB13131@redhat.com \
--to=oleg@redhat.com \
--cc=afazekas@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=asarai@suse.com \
--cc=ebiederm@xmission.com \
--cc=jann@thejh.net \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mhocko@kernel.org \
--cc=uobergfe@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).