From: Athira Rajeev <atrajeev@linux.ibm.com>
To: acme@kernel.org, jolsa@kernel.org, adrian.hunter@intel.com,
maddy@linux.ibm.com, irogers@google.com, namhyung@kernel.org
Cc: linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
atrajeev@linux.ibm.com, hbathini@linux.vnet.ibm.com,
tejas05@linux.ibm.com, tshah@linux.ibm.com,
venkat88@linux.ibm.com, narnalli@in.ibm.com, vpuliyal@in.ibm.com
Subject: [PATCH 3/3] perf buildid-cache: skip caching non-ELF files and treat unreadable build-id as mismatch
Date: Mon, 7 Sep 2026 09:15:54 +0530 [thread overview]
Message-ID: <20260907034554.714-3-atrajeev@linux.ibm.com> (raw)
In-Reply-To: <20260907034554.714-1-atrajeev@linux.ibm.com>
Two related hardening fixes for the build-id cache population path
(perf_session__cache_build_ids, called at the end of perf record):
1. build_id_cache__add(): Before hard-linking or copying a file into
the cache, verify it is a valid ELF using the shared is_valid_elf()
helper (introduced in patch 1/3). If it is not, emit a warning and
skip the cache write.
This prevents a race condition that can occur with test harnesses
such as SPEC CPU, which briefly rename the benchmark binary to a
.used.<pid> path and write a shell script placeholder there during
run-directory cleanup. If perf's cache write races with that window
-- seeing the renamed path in /proc/<pid>/maps and reading the
build-id from the still-valid inode, then copying the file after the
placeholder has been written -- the cache ends up containing the
shell script instead of the ELF. The ELF magic check catches this
at copy time.
2. dso__build_id_mismatch(): Previously, if filename__read_build_id_ns()
failed (e.g. the file is not an ELF, or has been replaced), the
function returned false (no mismatch), allowing caching to proceed
with whatever file happened to be at that path. Change the default
return value to true (mismatch) so that an unreadable build-id is
treated conservatively as a mismatch and caching is skipped.
Together these ensure that only genuine ELF binaries with a verifiable
build-id matching what perf recorded are written into the cache.
Reported-by: Narendra Nalli <narnalli@in.ibm.com>
Reported-by: Vijay Puliyala <vpuliyal@in.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
---
tools/perf/util/build-id.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 28b6b3f8d5d3..32ddbd5e61f6 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -684,6 +684,10 @@ build_id_cache__add(const char *sbuild_id, const char *name, const char *realnam
if (is_kallsyms) {
if (copyfile("/proc/kallsyms", filename))
goto out_free;
+ } else if (!is_valid_elf(realname)) {
+ pr_warning("build-id cache: skipping non-ELF file: %s\n",
+ realname);
+ goto out_free;
} else if (nsi && nsinfo__need_setns(nsi)) {
if (copyfile_ns(name, filename, nsi))
goto out_free;
@@ -874,7 +878,11 @@ static int filename__read_build_id_ns(const char *filename,
static bool dso__build_id_mismatch(struct dso *dso, const char *name)
{
struct build_id bid = { .size = 0, };
- bool ret = false;
+ /*
+ * Default to mismatch: if we cannot read the build-id (e.g. file
+ * replaced or not an ELF), treat it conservatively as a mismatch.
+ */
+ bool ret = true;
mutex_lock(dso__lock(dso));
if (filename__read_build_id_ns(name, &bid, dso__nsinfo(dso)) >= 0)
--
2.43.0
next prev parent reply other threads:[~2026-09-07 3:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 3:45 [PATCH 1/3] perf build-id: add shared is_valid_elf() helper Athira Rajeev
2026-09-07 3:45 ` [PATCH 2/3] perf annotate: fall back to original binary if build-id cache entry is not a valid ELF Athira Rajeev
2026-09-07 3:59 ` sashiko-bot
2026-09-07 3:45 ` Athira Rajeev [this message]
2026-09-07 4:01 ` [PATCH 3/3] perf buildid-cache: skip caching non-ELF files and treat unreadable build-id as mismatch sashiko-bot
2026-09-07 3:53 ` [PATCH 1/3] perf build-id: add shared is_valid_elf() helper sashiko-bot
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=20260907034554.714-3-atrajeev@linux.ibm.com \
--to=atrajeev@linux.ibm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=hbathini@linux.vnet.ibm.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=namhyung@kernel.org \
--cc=narnalli@in.ibm.com \
--cc=tejas05@linux.ibm.com \
--cc=tshah@linux.ibm.com \
--cc=venkat88@linux.ibm.com \
--cc=vpuliyal@in.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox