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 863ACC3F2CD for ; Mon, 2 Mar 2020 21:51:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4705E2465E for ; Mon, 2 Mar 2020 21:51:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4705E2465E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DF8BD6B0005; Mon, 2 Mar 2020 16:51:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D81436B0006; Mon, 2 Mar 2020 16:51:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C214C6B0007; Mon, 2 Mar 2020 16:51:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A5ECC6B0005 for ; Mon, 2 Mar 2020 16:51:26 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7C7288248047 for ; Mon, 2 Mar 2020 21:51:26 +0000 (UTC) X-FDA: 76551768972.25.boats53_80e3fb0d9fa13 X-HE-Tag: boats53_80e3fb0d9fa13 X-Filterd-Recvd-Size: 7275 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Mon, 2 Mar 2020 21:51:25 +0000 (UTC) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1j8sy9-0001uo-3P; Mon, 02 Mar 2020 14:51:21 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1j8sy8-0000vB-BX; Mon, 02 Mar 2020 14:51:20 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Bernd Edlinger Cc: Jann Horn , Christian Brauner , 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 , Kees Cook , 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" References: <20200301185244.zkofjus6xtgkx4s3@wittgenstein> <87a74zmfc9.fsf@x220.int.ebiederm.org> <87k142lpfz.fsf@x220.int.ebiederm.org> <875zfmloir.fsf@x220.int.ebiederm.org> Date: Mon, 02 Mar 2020 15:49:09 -0600 In-Reply-To: (Bernd Edlinger's message of "Mon, 2 Mar 2020 17:13:31 +0000") Message-ID: <87v9nmjulm.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1j8sy8-0000vB-BX;;;mid=<87v9nmjulm.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19moPzbn5KKuED00hBojlLEmyr3UzUKtvY= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCHv2] exec: Fix a deadlock in ptrace X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) 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: Bernd Edlinger writes: > On 3/2/20 5:17 PM, Eric W. Biederman wrote: >> Bernd Edlinger writes: >> >>> On 3/2/20 4:57 PM, Eric W. Biederman wrote: >>>> Bernd Edlinger writes: >>>> >>>>> >>>>> I tried this with s/EACCESS/EACCES/. >>>>> >>>>> The test case in this patch is not fixed, but strace does not freeze, >>>>> at least with my setup where it did freeze repeatable. >>>> >>>> Thanks, That is what I was aiming at. >>>> >>>> So we have one method we can pursue to fix this in practice. >>>> >>>>> That is >>>>> obviously because it bypasses the cred_guard_mutex. But all other >>>>> process that access this file still freeze, and cannot be >>>>> interrupted except with kill -9. >>>>> >>>>> However that smells like a denial of service, that this >>>>> simple test case which can be executed by guest, creates a /proc/$pid/mem >>>>> that freezes any process, even root, when it looks at it. >>>>> I mean: "ln -s README /proc/$pid/mem" would be a nice bomb. >>>> >>>> Yes. Your the test case in your patch a variant of the original >>>> problem. >>>> >>>> >>>> I have been staring at this trying to understand the fundamentals of the >>>> original deeper problem. >>>> >>>> The current scope of cred_guard_mutex in exec is because being ptraced >>>> causes suid exec to act differently. So we need to know early if we are >>>> ptraced. >>>> >>> >>> It has a second use, that it prevents two threads entering execve, >>> which would probably result in disaster. >> >> Exec can fail with an error code up until de_thread. de_thread causes >> exec to fail with the error code -EAGAIN for the second thread to get >> into de_thread. >> >> So no. The cred_guard_mutex is not needed for that case at all. >> > > Okay, but that will reset current->in_execve, right? Absolutely. The error handling kicks in and exec_binprm fails with a negative return code. Then __do_excve_file cleans up and clears current->in_execve. Eric