From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Jann Horn <jannh@google.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Arjan van de Ven <arjan@linux.intel.com>,
Jake Edge <jake@lwn.net>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
stable@vger.kernel.org, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 0/2] proc: protect ptrace_may_access() with exec_update_lock
Date: Tue, 26 May 2026 13:10:45 +0200 [thread overview]
Message-ID: <ahV_teQZlF5hhYHf@redhat.com> (raw)
In-Reply-To: <87ik8b2rh8.fsf@email.froward.int.ebiederm.org>
On 05/25, Eric W. Biederman wrote:
>
> The ugly with PTRACE_EVENT_EXIT as I recall is that if ptrace stops one
> of the threads (not the one calling exec) at PTRACE_EVENT_EXIT it can
> block de_thread, which blocks the rest of exec. But there is something
> in there where the ptracer hangs waiting for the exec to complete. So
> everything just stalls. The ptracer waiting for exec the exec waiting
> for the ptracer. SIGKILL can get you out of that mess last I looked.
> Still it is an ugly mess.
Yes... note that even without PTRACE_EVENT_EXIT a traced sub-thread won't
autoreap, so de_thread which waits for --sig->notify_count in __exit_signal()
will block anyway.
Perhaps we can change ptrace_attach() to detect this case somehow and return
-EWOULDBLOCK... Yes this can confuse strace/gdb, but this is better than
the deadlock, even if it is killable.
Oleg.
next prev parent reply other threads:[~2026-05-26 11:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 16:35 [PATCH 0/2] proc: protect ptrace_may_access() with exec_update_lock Jann Horn
2026-05-18 16:35 ` [PATCH 1/2] proc: protect ptrace_may_access() with exec_update_lock (part 1) Jann Horn
2026-05-26 8:48 ` Oleg Nesterov
2026-05-26 9:44 ` Oleg Nesterov
2026-05-26 14:19 ` Jann Horn
2026-05-26 14:16 ` Jann Horn
2026-05-26 18:22 ` Oleg Nesterov
2026-05-26 18:30 ` Jann Horn
2026-06-05 14:36 ` Mark Brown
2026-06-05 14:39 ` Jann Horn
2026-05-18 16:35 ` [PATCH 2/2] proc: protect ptrace_may_access() with exec_update_lock (FD links) Jann Horn
2026-05-22 11:47 ` [PATCH 0/2] proc: protect ptrace_may_access() with exec_update_lock Christian Brauner
2026-05-25 19:56 ` Eric W. Biederman
2026-05-26 11:10 ` Oleg Nesterov [this message]
2026-05-26 18:22 ` Jann Horn
2026-05-27 12:01 ` Christian Brauner
2026-05-27 12:31 ` Christian Brauner
2026-05-27 13:49 ` Jann Horn
2026-05-27 13:44 ` Jann Horn
2026-05-27 13:57 ` Christian Brauner
[not found] ` <87wlwny905.fsf@email.froward.int.ebiederm.org>
2026-05-28 14:20 ` Jann Horn
[not found] ` <87mrx9f8q2.fsf@email.froward.int.ebiederm.org>
2026-06-05 14:34 ` Jann Horn
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=ahV_teQZlF5hhYHf@redhat.com \
--to=oleg@redhat.com \
--cc=arjan@linux.intel.com \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=jake@lwn.net \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--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.