From: Kees Cook <keescook@chromium.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-api@vger.kernel.org
Subject: Re: [PATCH 3/6] exec: Check for a pending fatal signal instead of core_state
Date: Fri, 24 Sep 2021 08:38:41 -0700 [thread overview]
Message-ID: <202109240834.8D3A18AC32@keescook> (raw)
In-Reply-To: <87fstux27w.fsf@disp2133>
On Thu, Sep 23, 2021 at 07:10:43PM -0500, Eric W. Biederman wrote:
>
> Prevent exec continuing when a fatal signal is pending by replacing
> mmap_read_lock with mmap_read_lock_killable. This is always the right
> thing to do as userspace will never observe an exec complete when
> there is a fatal signal pending.
>
> With that change it becomes unnecessary to explicitly test for a core
> dump in progress. In coredump_wait zap_threads arranges under
> mmap_write_lock for all tasks that use a mm to also have SIGKILL
> pending, which means mmap_read_lock_killable will always return -EINTR
> when old_mm->core_state is present.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
> fs/exec.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/fs/exec.c b/fs/exec.c
> index a098c133d8d7..b6079f1a098e 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -987,16 +987,14 @@ static int exec_mmap(struct mm_struct *mm)
>
> if (old_mm) {
> /*
> - * Make sure that if there is a core dump in progress
> - * for the old mm, we get out and die instead of going
> - * through with the exec. We must hold mmap_lock around
> - * checking core_state and changing tsk->mm.
> + * If there is a pending fatal signal perhaps a signal
> + * whose default action is to create a coredump get
> + * out and die instead of going through with the exec.
> */
> - mmap_read_lock(old_mm);
> - if (unlikely(old_mm->core_state)) {
> - mmap_read_unlock(old_mm);
> + ret = mmap_read_lock_killable(old_mm);
This appears to ultimately call into rwsem_down_read_slowpath(), which
checks signal_pending_state() (and returns the EINTR from before),
so this looks right to me.
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> + if (ret) {
> up_write(&tsk->signal->exec_update_lock);
> - return -EINTR;
> + return ret;
> }
> }
>
> --
> 2.20.1
>
--
Kees Cook
next prev parent reply other threads:[~2021-09-24 15:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 0:08 [PATCH 0/6] per signal_struct coredumps Eric W. Biederman
2021-09-24 0:09 ` [PATCH 1/6] signal: Remove the bogus sigkill_pending in ptrace_stop Eric W. Biederman
2021-09-24 15:22 ` Kees Cook
2021-09-24 15:48 ` Eric W. Biederman
2021-09-24 19:06 ` Kees Cook
2021-09-24 0:10 ` [PATCH 2/6] ptrace: Remove the unnecessary arguments from arch_ptrace_stop Eric W. Biederman
2021-09-24 15:26 ` Kees Cook
2021-09-24 0:10 ` [PATCH 3/6] exec: Check for a pending fatal signal instead of core_state Eric W. Biederman
2021-09-24 15:38 ` Kees Cook [this message]
2021-09-24 0:11 ` [PATCH 4/6] exit: Factor coredump_exit_mm out of exit_mm Eric W. Biederman
2021-09-24 18:28 ` Kees Cook
2021-09-24 0:11 ` [PATCH 5/6] coredump: Don't perform any cleanups before dumping core Eric W. Biederman
2021-09-24 18:51 ` Kees Cook
2021-09-24 21:28 ` Eric W. Biederman
2021-09-24 21:41 ` Kees Cook
2021-09-24 0:12 ` [PATCH 6/6] coredump: Limit coredumps to a single thread group Eric W. Biederman
2021-09-24 18:56 ` Kees Cook
2021-10-06 17:03 ` Eric W. Biederman
2021-11-19 16:03 ` Kyle Huey
2021-11-19 17:38 ` Eric W. Biederman
2021-09-24 5:59 ` [PATCH 0/6] per signal_struct coredumps Kees Cook
2021-09-24 14:00 ` Eric W. Biederman
2021-09-24 15:22 ` [PATCH 2/6] ptrace: Remove the unnecessary arguments from arch_ptrace_stop Eric W. Biederman
2021-09-24 15:22 ` Eric W. Biederman
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=202109240834.8D3A18AC32@keescook \
--to=keescook@chromium.org \
--cc=ebiederm@xmission.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.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.