From: ebiederm@xmission.com (Eric W. Biederman)
To: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Kees Cook <keescook@chromium.org>,
"linux-fsdevel\@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Fix error handling in begin_new_exec
Date: Sun, 06 Jun 2021 14:34:53 -0500 [thread overview]
Message-ID: <87mts2kcrm.fsf@disp2133> (raw)
In-Reply-To: <AM8PR10MB47081071E64EAAB343196D5AE4399@AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM> (Bernd Edlinger's message of "Sun, 6 Jun 2021 12:41:18 +0200")
Bernd Edlinger <bernd.edlinger@hotmail.de> 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" <ebiederm@xmission.com>
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 <bernd.edlinger@hotmail.de>
> ---
> 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;
> }
next prev parent reply other threads:[~2021-06-06 19:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-06 10:41 [PATCH] Fix error handling in begin_new_exec Bernd Edlinger
2021-06-06 19:34 ` Eric W. Biederman [this message]
2023-10-30 5:50 ` Bernd Edlinger
2024-01-15 19:22 ` [PATCH v2] " Bernd Edlinger
2024-01-22 18:34 ` [PATCH v3] " Bernd Edlinger
2024-01-22 20:53 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mts2kcrm.fsf@disp2133 \
--to=ebiederm@xmission.com \
--cc=bernd.edlinger@hotmail.de \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.