From: Kees Cook <kees@kernel.org>
To: Nam Cao <namcao@linutronix.de>
Cc: Shuah Khan <shuah@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Dylan Hatch <dylanbhatch@google.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
John Ogness <john.ogness@linutronix.de>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kselftest@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/2] fs/proc: do_task_stat: Fix ESP not readable during coredump
Date: Mon, 30 Dec 2024 10:43:58 -0800 [thread overview]
Message-ID: <202412301043.78340B2FD@keescook> (raw)
In-Reply-To: <c2f1b742c2b8f230f8e0ffa10a061116934dcf5b.1735550994.git.namcao@linutronix.de>
On Mon, Dec 30, 2024 at 11:17:30AM +0100, Nam Cao wrote:
> The field "eip" (instruction pointer) and "esp" (stack pointer) of a task
> can be read from /proc/PID/stat. These fields can be interesting for
> coredump.
>
> However, these fields were disabled by commit 0a1eb2d474ed ("fs/proc: Stop
> reporting eip and esp in /proc/PID/stat"), because it is generally unsafe
> to do so. But it is safe for a coredumping process, and therefore
> exceptions were made:
>
> - for a coredumping thread by commit fd7d56270b52 ("fs/proc: Report
> eip/esp in /prod/PID/stat for coredumping").
>
> - for all other threads in a coredumping process by commit cb8f381f1613
> ("fs/proc/array.c: allow reporting eip/esp for all coredumping
> threads").
>
> The above two commits check the PF_DUMPCORE flag to determine a coredump thread
> and the PF_EXITING flag for the other threads.
>
> Unfortunately, commit 92307383082d ("coredump: Don't perform any cleanups
> before dumping core") moved coredump to happen earlier and before PF_EXITING is
> set. Thus, checking PF_EXITING is no longer the correct way to determine
> threads in a coredumping process.
>
> Instead of PF_EXITING, use PF_POSTCOREDUMP to determine the other threads.
>
> Checking of PF_EXITING was added for coredumping, so it probably can now be
> removed. But it doesn't hurt to keep.
>
> Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core")
> Cc: stable@vger.kernel.org
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Acked-by: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Thanks for fixing this!
Acked-by: Kees Cook <kees@kernel.org>
--
Kees Cook
next prev parent reply other threads:[~2024-12-30 18:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 10:17 [PATCH v2 0/2] fix reading ESP during coredump Nam Cao
2024-12-30 10:17 ` [PATCH v2 1/2] fs/proc: do_task_stat: Fix ESP not readable " Nam Cao
2024-12-30 18:43 ` Kees Cook [this message]
2024-12-30 10:17 ` [PATCH v2 2/2] selftests: coredump: Add stackdump test Nam Cao
2024-12-30 18:43 ` 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=202412301043.78340B2FD@keescook \
--to=kees@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dylanbhatch@google.com \
--cc=ebiederm@xmission.com \
--cc=john.ogness@linutronix.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=namcao@linutronix.de \
--cc=oleg@redhat.com \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
/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.