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
| ||
|
Date: Mon, 2 Mar 2020 15:56:04 +0000 From: Bernd Edlinger <bernd.edlinger@...mail.de> To: Oleg Nesterov <oleg@...hat.com> CC: Jann Horn <jannh@...gle.com>, Christian Brauner <christian.brauner@...ntu.com>, Jonathan Corbet <corbet@....net>, Alexander Viro <viro@...iv.linux.org.uk>, Andrew Morton <akpm@...ux-foundation.org>, Alexey Dobriyan <adobriyan@...il.com>, "Eric W. Biederman" <ebiederm@...ssion.com>, Thomas Gleixner <tglx@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>, Andrei Vagin <avagin@...il.com>, Ingo Molnar <mingo@...nel.org>, "Peter Zijlstra (Intel)" <peterz@...radead.org>, Yuyang Du <duyuyang@...il.com>, David Hildenbrand <david@...hat.com>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Anshuman Khandual <anshuman.khandual@....com>, David Howells <dhowells@...hat.com>, James Morris <jamorris@...ux.microsoft.com>, Kees Cook <keescook@...omium.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Shakeel Butt <shakeelb@...gle.com>, Jason Gunthorpe <jgg@...pe.ca>, Christian Kellner <christian@...lner.me>, Andrea Arcangeli <aarcange@...hat.com>, Aleksa Sarai <cyphar@...har.com>, "Dmitry V. Levin" <ldv@...linux.org>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "stable@...r.kernel.org" <stable@...r.kernel.org> Subject: Re: [PATCHv2] exec: Fix a deadlock in ptrace On 3/2/20 1:28 PM, Oleg Nesterov wrote: > On 03/01, Bernd Edlinger wrote: >> >> This fixes a deadlock in the tracer when tracing a multi-threaded >> application that calls execve while more than one thread are running. > > Heh. Yes, known problem. See my attempt to fix it: > https://lore.kernel.org/lkml/20170213141452.GA30203@redhat.com/ > >> @@ -1224,7 +1224,7 @@ struct mm_struct *mm_access(struct task_struct *task, unsigned int mode) >> struct mm_struct *mm; >> int err; >> >> - err = mutex_lock_killable(&task->signal->cred_guard_mutex); >> + err = mutex_lock_killable(&task->signal->cred_change_mutex); > > So if I understand correctly your patch doesn't fix other problems > with debugger waiting for cred_guard_mutex. > No, but I see this just as a first step. > I too do not think this can justify the new mutex in signal_struct... > I think for the vm_access the semantic of this mutex is clear, that it prevents the credentials to change while it is held by vm_access, and probably other places can take advantage of this mutex as well. While on the other hand, the cred_guard_mutex is needed to avoid two threads calling execve at the same time. So that is needed as well. What remains is probably making PTHREAD_ATTACH detect that the process is currently in execve, and make that call fail in that situation. I have not thought in depth about that problem, but it will probably just need the right mutex to access current->in_execve. That's at least how I see it. Thanks Bernd.
Powered by blists - more mailing lists