linux-kernel - Re: [PATCH v18] exec: Fix dead-lock in de_thread with ptrace

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]

Message-ID: <87wm3ky5n9.fsf@email.froward.int.ebiederm.org>
Date: Thu, 20 Nov 2025 11:29:14 -0600
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Bernd Edlinger <bernd.edlinger@...mail.de>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,  Alexey Dobriyan
 <adobriyan@...il.com>,  Oleg Nesterov <oleg@...hat.com>,  Kees Cook
 <kees@...nel.org>,  Andy Lutomirski <luto@...capital.net>,  Will Drewry
 <wad@...omium.org>,  Christian Brauner <brauner@...nel.org>,  Andrew
 Morton <akpm@...ux-foundation.org>,  Michal Hocko <mhocko@...e.com>,
  Serge Hallyn <serge@...lyn.com>,  James Morris
 <jamorris@...ux.microsoft.com>,  Randy Dunlap <rdunlap@...radead.org>,
  Suren Baghdasaryan <surenb@...gle.com>,  Yafang Shao
 <laoar.shao@...il.com>,  Helge Deller <deller@....de>,  Adrian Reber
 <areber@...hat.com>,  Thomas Gleixner <tglx@...utronix.de>,  Jens Axboe
 <axboe@...nel.dk>,  Alexei Starovoitov <ast@...nel.org>,
  "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
  "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
  linux-kselftest@...r.kernel.org,  linux-mm@...ck.org,
  linux-security-module@...r.kernel.org,  tiozhang
 <tiozhang@...iglobal.com>,  Luis Chamberlain <mcgrof@...nel.org>,  "Paulo
 Alcantara (SUSE)" <pc@...guebit.com>,  Sergey Senozhatsky
 <senozhatsky@...omium.org>,  Frederic Weisbecker <frederic@...nel.org>,
  YueHaibing <yuehaibing@...wei.com>,  Paul Moore <paul@...l-moore.com>,
  Aleksa Sarai <cyphar@...har.com>,  Stefan Roesch <shr@...kernel.io>,
  Chao Yu <chao@...nel.org>,  xu xin <xu.xin16@....com.cn>,  Jeff Layton
 <jlayton@...nel.org>,  Jan Kara <jack@...e.cz>,  David Hildenbrand
 <david@...hat.com>,  Dave Chinner <dchinner@...hat.com>,  Shuah Khan
 <shuah@...nel.org>,  Elena Reshetova <elena.reshetova@...el.com>,  David
 Windsor <dwindsor@...il.com>,  Mateusz Guzik <mjguzik@...il.com>,  Ard
 Biesheuvel <ardb@...nel.org>,  "Joel Fernandes (Google)"
 <joel@...lfernandes.org>,  "Matthew Wilcox (Oracle)"
 <willy@...radead.org>,  Hans Liljestrand <ishkamiel@...il.com>,  Penglei
 Jiang <superman.xpt@...il.com>,  Lorenzo Stoakes
 <lorenzo.stoakes@...cle.com>,  Adrian Ratiu <adrian.ratiu@...labora.com>,
  Ingo Molnar <mingo@...nel.org>,  "Peter Zijlstra (Intel)"
 <peterz@...radead.org>,  Cyrill Gorcunov <gorcunov@...il.com>,  Eric
 Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH v18] exec: Fix dead-lock in de_thread with ptrace_attach

"Eric W. Biederman" <ebiederm@...ssion.com> writes:

> Bernd Edlinger <bernd.edlinger@...mail.de> writes:
>
>> This introduces signal->exec_bprm, which is used to
>> fix the case when at least one of the sibling threads
>> is traced, and therefore the trace process may dead-lock
>> in ptrace_attach, but de_thread will need to wait for the
>> tracer to continue execution.
>
> A small quibble it isn't a dead lock.  It isn't even really a live lock,
> as it is possible to SIGKILL our way out.
>
> Thinking about this there is a really silly and simple way we can deal
> with this situation for PTRACE_ATTACH.  We can send SIGSTOP and wait for
> the thread to stop before doing anything with cred_guard_mutex.
>
> PTRACE_ATTACH already implies sending SIGSTOP so as long as we have
> enough permissions to send SIGSTOP I don't see that being a problem.
>
> The worst case I can see is that we get a case where we stop the
> process, the permission check fails under cred_guard_mutex and
> and ptrace attach has fails and has to send SIGCONT to undo it's
> premature SIGSTOP.  That might almost be visible, but it would still
> be legitimate because we can still check that we have permission to
> send SIGSTOP.

Bah no I am full of it.

The challenging behavior is in the semantics of the kernel operations.
We need to describe it as such please.

It is the same class of problem as a single threaded process calls exec
with a pipe attached to both stdin and stdout of the new process.

For the stdin and stdout we can say just use pull and nonblocking I/O.

The problem is that both PTRACE_ATTACH and PTRACE_SEIZE block over
the duration of exec, and if exec is waiting for a thread to exit,
and that thread is blocked in PTRACE_EVENT_EXIT waiting for that very
same tracer those processes will hang. Not deadlock.

I haven't seen anyone clearly describe the problem lately so I am
repeating it.

Just looking at the code I don't think there is any fundamental reason
to call commit_creds after de_thread.  If we can change that we can sort
this out without any change in userspace semantics.

If we can't move commit_creds we have to either give
PTRACE_ATTACH/PTRACE_SEIZE a non-block mode, or break out of
PTRACE_EVENT_EXIT in de_thread.

I will post a proof of concept of moving commit_creds in just a minute.

Eric