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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 59D2FC4743D for ; Sun, 6 Jun 2021 19:35:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3C9456138C for ; Sun, 6 Jun 2021 19:35:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229573AbhFFThH (ORCPT ); Sun, 6 Jun 2021 15:37:07 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:39050 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229721AbhFFThF (ORCPT ); Sun, 6 Jun 2021 15:37:05 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lpyYE-00FlQA-8k; Sun, 06 Jun 2021 13:35:14 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=email.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lpyYD-007nKe-97; Sun, 06 Jun 2021 13:35:13 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Bernd Edlinger Cc: Alexander Viro , Kees Cook , "linux-fsdevel\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" References: Date: Sun, 06 Jun 2021 14:34:53 -0500 In-Reply-To: (Bernd Edlinger's message of "Sun, 6 Jun 2021 12:41:18 +0200") Message-ID: <87mts2kcrm.fsf@disp2133> 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=1lpyYD-007nKe-97;;;mid=<87mts2kcrm.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19tkxyVQPNifWvgwI/68HlKr0bp7WhB3vk= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] Fix error handling in begin_new_exec X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bernd Edlinger writes: > If get_unused_fd_flags() fails, the error handling is incomplete > because bprm->cred is already set to NULL, and therefore > free_bprm will not unlock the cred_guard_mutex. > Note there are two error conditions which end up here, > one before and one after bprm->cred is cleared. Acked-by: "Eric W. Biederman" Yuck. I wonder if there is a less error prone idiom we could be using here than testing bprm->cred in free_bprm. Especially as this lock is expected to stay held through setup_new_exec. Something feels too clever here. > Fixes: b8a61c9e7b4 ("exec: Generic execfd support") > > Signed-off-by: Bernd Edlinger > --- > fs/exec.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/exec.c b/fs/exec.c > index 18594f1..d8af85f 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1396,6 +1396,9 @@ int begin_new_exec(struct linux_binprm * bprm) > > out_unlock: > up_write(&me->signal->exec_update_lock); > + if (!bprm->cred) > + mutex_unlock(&me->signal->cred_guard_mutex); > + > out: > return retval; > }