From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 584CCC3F2CD for ; Tue, 3 Mar 2020 14:21:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 20D3220838 for ; Tue, 3 Mar 2020 14:21:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20D3220838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BA7E66B0005; Tue, 3 Mar 2020 09:21:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B571F6B0006; Tue, 3 Mar 2020 09:21:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6CD16B0007; Tue, 3 Mar 2020 09:21:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id 8C2E26B0005 for ; Tue, 3 Mar 2020 09:21:26 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 596834995EA for ; Tue, 3 Mar 2020 14:21:26 +0000 (UTC) X-FDA: 76554263772.17.tiger57_299bae0149b12 X-HE-Tag: tiger57_299bae0149b12 X-Filterd-Recvd-Size: 4207 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Mar 2020 14:21:25 +0000 (UTC) Received: from ip5f5bf7ec.dynamic.kabel-deutschland.de ([95.91.247.236] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1j98Pg-0002Id-SV; Tue, 03 Mar 2020 14:20:49 +0000 Date: Tue, 3 Mar 2020 15:20:47 +0100 From: Christian Brauner To: Bernd Edlinger Cc: Kees Cook , "Eric W. Biederman" , Jann Horn , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra (Intel)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , James Morris , Greg Kroah-Hartman , Shakeel Butt , Jason Gunthorpe , Christian Kellner , Andrea Arcangeli , Aleksa Sarai , "Dmitry V. Levin" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "stable@vger.kernel.org" Subject: Re: [PATCHv4] exec: Fix a deadlock in ptrace Message-ID: <20200303142047.mrenhvhihe5sm5wv@wittgenstein> References: <87k142lpfz.fsf@x220.int.ebiederm.org> <875zfmloir.fsf@x220.int.ebiederm.org> <87v9nmjulm.fsf@x220.int.ebiederm.org> <202003021531.C77EF10@keescook> <20200303085802.eqn6jbhwxtmz4j2x@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 03, 2020 at 11:23:31AM +0000, Bernd Edlinger wrote: > On 3/3/20 11:34 AM, Bernd Edlinger wrote: > > On 3/3/20 9:58 AM, Christian Brauner wrote: > >> So one issue I see with having to reacquire the cred_guard_mutex might > >> be that this would allow tasks holding the cred_guard_mutex to block a > >> killed exec'ing task from exiting, right? > >> > > > > Yes maybe, but I think it will not be worse than it is now. > > Since the second time the mutex is acquired it is done with > > mutex_lock_killable, so at least kill -9 should get it terminated. > > > > > > > static void free_bprm(struct linux_binprm *bprm) > > { > > free_arg_pages(bprm); > > if (bprm->cred) { > > + if (!bprm->called_flush_old_exec) > > + mutex_lock(¤t->signal->cred_guard_mutex); > > + current->signal->cred_locked_for_ptrace = false; > > mutex_unlock(¤t->signal->cred_guard_mutex); > > > Hmm, cough... > actually when the mutex_lock_killable fails, due to kill -9, in flush_old_exec > free_bprm locks the same mutex, this time unkillable, but I should better do > mutex_lock_killable here, and if that fails, I can leave cred_locked_for_ptrace, > it shouldn't matter, since this is a fatal signal anyway, right? I think so, yes.