[PATCH v2] perf dso: Fix kallsyms DSO detection with fallback logic

[PATCH v2] perf dso: Fix kallsyms DSO detection with fallback logic

[Tanushree Shah]

The current kallsyms detection in dso__is_kallsyms() uses the
dso_binary_type enum which fixes the issue of kallsyms being cached in
the build-id cache for out-of-tree modules.

However, during build-id injection in perf record/inject, dso_binary_type
has not been explicitly set yet,so dso__binary_type() returns
DSO_BINARY_TYPE__NOT_FOUND instead of DSO_BINARY_TYPE__KALLSYMS for the
kernel DSO. The current check then fails to identify it as kallsyms,
causing build-id symlinks to not be created in ~/.debug/.build-id/ and
perf archive to fail with "Cannot stat" errors.

Steps to reproduce the issue:
1. rm -rf ~/.debug/.build-id
2. perf record sleep 1
3. perf archive

Fix by falling back to matching long_name against the known kallsyms
strings explicitly when binary_type is not yet set
(== DSO_BINARY_TYPE__NOT_FOUND).

Fixes: ebf0b332732d ("perf dso: fix dso__is_kallsyms() check")
Signed-off-by: Tanushree Shah <tshah@linux.ibm.com>
---
v1 -> v2: Rename DSO__NAME_GUEST_KALLSYMS to DSO__PREFIX_GUEST_KALLSYMS
          to reflect that it is a prefix, not a full name.

v1: https://lore.kernel.org/all/20260410071225.708005-2-tshah@linux.ibm.com/

 tools/perf/util/dso.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index ede691e9a249..515ab6e95b0e 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -9,6 +9,7 @@
 #include <stdbool.h>
 #include <stdio.h>
 #include <linux/bitops.h>
+#include <string.h>
 #include "build-id.h"
 #include "debuginfo.h"
 #include "mutex.h"
@@ -20,6 +21,7 @@ struct perf_env;
 
 #define DSO__NAME_KALLSYMS	"[kernel.kallsyms]"
 #define DSO__NAME_KCORE		"[kernel.kcore]"
+#define DSO__PREFIX_GUEST_KALLSYMS	"[guest.kernel.kallsyms"
 
 /**
  * enum dso_binary_type - The kind of DSO generally associated with a memory
@@ -915,6 +917,14 @@ static inline bool dso__is_kallsyms(const struct dso *dso)
 {
 	enum dso_binary_type bt = dso__binary_type(dso);
 
+	if (bt == DSO_BINARY_TYPE__NOT_FOUND) {
+		return RC_CHK_ACCESS(dso)->kernel &&
+			((strncmp(RC_CHK_ACCESS(dso)->long_name, DSO__NAME_KALLSYMS,
+				strlen(DSO__NAME_KALLSYMS)) == 0) ||
+			(strncmp(RC_CHK_ACCESS(dso)->long_name, DSO__PREFIX_GUEST_KALLSYMS,
+				strlen(DSO__PREFIX_GUEST_KALLSYMS)) == 0));
+	}
+
 	return bt == DSO_BINARY_TYPE__KALLSYMS || bt == DSO_BINARY_TYPE__GUEST_KALLSYMS;
 }
 
-- 
2.47.3

Re: [PATCH v2] perf dso: Fix kallsyms DSO detection with fallback logic

[sashiko-bot]

Sashiko AI review found 2 potential issue(s):
- [High] Path Traversal and Information Disclosure due to `strncmp` matching any prefix.
- [Medium] Incomplete fix: Fallback logic is missing from `dso__is_kcore()` and `dso__is_vmlinux()`.
--

commit 9ee80283f13c6a0a5235a2add7a94736c1dfcbba
Author: Tanushree Shah <tshah@linux.ibm.com>

perf dso: Fix kallsyms DSO detection with fallback logic

This commit fixes an issue where kallsyms DSOs are not correctly identified
during build-id injection because the dso_binary_type is not yet set. It
adds a fallback string matching check against the DSO's long_name.

> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> index ede691e9a2495..515ab6e95b0e4 100644
> --- a/tools/perf/util/dso.h
> +++ b/tools/perf/util/dso.h

[ ... ]

> @@ -915,6 +917,14 @@ static inline bool dso__is_kallsyms(const struct dso *dso)
>  {
>  	enum dso_binary_type bt = dso__binary_type(dso);
>  
> +	if (bt == DSO_BINARY_TYPE__NOT_FOUND) {

Since the fallback logic was added here because dso_binary_type(dso) is
DSO_BINARY_TYPE__NOT_FOUND during perf record and inject, do dso__is_kcore()
and dso__is_vmlinux() require a similar fallback?

Looking at dso__cache_build_id(), it relies on dso__is_kcore() to flag the
DSO for special caching logic. If dso__is_kcore() returns false during
build-id caching, kcore DSOs are treated as regular files, which causes
nsinfo__realpath() to fail and breaks perf archive for kcore sessions.

> +		return RC_CHK_ACCESS(dso)->kernel &&
> +			((strncmp(RC_CHK_ACCESS(dso)->long_name, DSO__NAME_KALLSYMS,
> +				strlen(DSO__NAME_KALLSYMS)) == 0) ||

Does using strncmp() here allow a path traversal if long_name is
intentionally crafted?

If a malicious perf.data file contains an MMAP event with a filename like
"[kernel.kallsyms]/../../../../tmp/leak", this prefix check evaluates
to true.

Could this allow build_id_cache__cachedir() to construct a cache directory
using this malicious path, causing build_id_cache__add() to unconditionally
copy the host's /proc/kallsyms into an attacker-controlled directory?

> +			(strncmp(RC_CHK_ACCESS(dso)->long_name, DSO__PREFIX_GUEST_KALLSYMS,
> +				strlen(DSO__PREFIX_GUEST_KALLSYMS)) == 0));
> +	}
> +
>  	return bt == DSO_BINARY_TYPE__KALLSYMS || bt == DSO_BINARY_TYPE__GUEST_KALLSYMS;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260416091657.578429-2-tshah@linux.ibm.com?part=1

Re: [PATCH v2] perf dso: Fix kallsyms DSO detection with fallback logic

[Tanushree Shah]

On 16/04/26 16:39, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 2 potential issue(s):
> - [High] Path Traversal and Information Disclosure due to `strncmp` matching any prefix.
> - [Medium] Incomplete fix: Fallback logic is missing from `dso__is_kcore()` and `dso__is_vmlinux()`.
> --
> 
> commit 9ee80283f13c6a0a5235a2add7a94736c1dfcbba
> Author: Tanushree Shah <tshah@linux.ibm.com>
> 
> perf dso: Fix kallsyms DSO detection with fallback logic
> 
> This commit fixes an issue where kallsyms DSOs are not correctly identified
> during build-id injection because the dso_binary_type is not yet set. It
> adds a fallback string matching check against the DSO's long_name.
> 
>> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
>> index ede691e9a2495..515ab6e95b0e4 100644
>> --- a/tools/perf/util/dso.h
>> +++ b/tools/perf/util/dso.h
> 
> [ ... ]
> 
>> @@ -915,6 +917,14 @@ static inline bool dso__is_kallsyms(const struct dso *dso)
>>   {
>>   	enum dso_binary_type bt = dso__binary_type(dso);
>>   
>> +	if (bt == DSO_BINARY_TYPE__NOT_FOUND) {
> 
> Since the fallback logic was added here because dso_binary_type(dso) is
> DSO_BINARY_TYPE__NOT_FOUND during perf record and inject, do dso__is_kcore()
> and dso__is_vmlinux() require a similar fallback?
> 
> Looking at dso__cache_build_id(), it relies on dso__is_kcore() to flag the
> DSO for special caching logic. If dso__is_kcore() returns false during
> build-id caching, kcore DSOs are treated as regular files, which causes
> nsinfo__realpath() to fail and breaks perf archive for kcore sessions.
> 
>> +		return RC_CHK_ACCESS(dso)->kernel &&
>> +			((strncmp(RC_CHK_ACCESS(dso)->long_name, DSO__NAME_KALLSYMS,
>> +				strlen(DSO__NAME_KALLSYMS)) == 0) ||
> 
> Does using strncmp() here allow a path traversal if long_name is
> intentionally crafted?
> 
> If a malicious perf.data file contains an MMAP event with a filename like
> "[kernel.kallsyms]/../../../../tmp/leak", this prefix check evaluates
> to true.
> 
> Could this allow build_id_cache__cachedir() to construct a cache directory
> using this malicious path, causing build_id_cache__add() to unconditionally
> copy the host's /proc/kallsyms into an attacker-controlled directory?

Hello,
The current code relies on dso_binary_type to check if its a kallsyms 
dso. While running perf archive, the code calls dso__is_kallsyms check 
to create a build-id dir. But till that time, dso_binary_type is not 
getting set yet. Hence, this patch introduced usage of dso->long_name to 
check if it is kallsyms. But based on the above review from Sashiko, it 
seems that this may create a security concern.

I tried to check for the possibility to set the dso binary type before
dso__is_kallsyms gets called. But, I found that dso binary type is 
getting set based on dso__is_kallsyms only.

So, I am looking for suggestions/approach that we can take here.

Thanks
Tanushree Shah

> 
>> +			(strncmp(RC_CHK_ACCESS(dso)->long_name, DSO__PREFIX_GUEST_KALLSYMS,
>> +				strlen(DSO__PREFIX_GUEST_KALLSYMS)) == 0));
>> +	}
>> +
>>   	return bt == DSO_BINARY_TYPE__KALLSYMS || bt == DSO_BINARY_TYPE__GUEST_KALLSYMS;
>>   }
> 

Re: [PATCH v2] perf dso: Fix kallsyms DSO detection with fallback logic

[Namhyung Kim]

On Thu, Jun 11, 2026 at 06:04:23PM +0530, Tanushree Shah wrote:
> 
> 
> On 16/04/26 16:39, sashiko-bot@kernel.org wrote:
> > Sashiko AI review found 2 potential issue(s):
> > - [High] Path Traversal and Information Disclosure due to `strncmp` matching any prefix.
> > - [Medium] Incomplete fix: Fallback logic is missing from `dso__is_kcore()` and `dso__is_vmlinux()`.
> > --
> > 
> > commit 9ee80283f13c6a0a5235a2add7a94736c1dfcbba
> > Author: Tanushree Shah <tshah@linux.ibm.com>
> > 
> > perf dso: Fix kallsyms DSO detection with fallback logic
> > 
> > This commit fixes an issue where kallsyms DSOs are not correctly identified
> > during build-id injection because the dso_binary_type is not yet set. It
> > adds a fallback string matching check against the DSO's long_name.
> > 
> > > diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> > > index ede691e9a2495..515ab6e95b0e4 100644
> > > --- a/tools/perf/util/dso.h
> > > +++ b/tools/perf/util/dso.h
> > 
> > [ ... ]
> > 
> > > @@ -915,6 +917,14 @@ static inline bool dso__is_kallsyms(const struct dso *dso)
> > >   {
> > >   	enum dso_binary_type bt = dso__binary_type(dso);
> > > +	if (bt == DSO_BINARY_TYPE__NOT_FOUND) {
> > 
> > Since the fallback logic was added here because dso_binary_type(dso) is
> > DSO_BINARY_TYPE__NOT_FOUND during perf record and inject, do dso__is_kcore()
> > and dso__is_vmlinux() require a similar fallback?
> > 
> > Looking at dso__cache_build_id(), it relies on dso__is_kcore() to flag the
> > DSO for special caching logic. If dso__is_kcore() returns false during
> > build-id caching, kcore DSOs are treated as regular files, which causes
> > nsinfo__realpath() to fail and breaks perf archive for kcore sessions.
> > 
> > > +		return RC_CHK_ACCESS(dso)->kernel &&
> > > +			((strncmp(RC_CHK_ACCESS(dso)->long_name, DSO__NAME_KALLSYMS,
> > > +				strlen(DSO__NAME_KALLSYMS)) == 0) ||
> > 
> > Does using strncmp() here allow a path traversal if long_name is
> > intentionally crafted?
> > 
> > If a malicious perf.data file contains an MMAP event with a filename like
> > "[kernel.kallsyms]/../../../../tmp/leak", this prefix check evaluates
> > to true.
> > 
> > Could this allow build_id_cache__cachedir() to construct a cache directory
> > using this malicious path, causing build_id_cache__add() to unconditionally
> > copy the host's /proc/kallsyms into an attacker-controlled directory?
> 
> Hello,
> The current code relies on dso_binary_type to check if its a kallsyms dso.
> While running perf archive, the code calls dso__is_kallsyms check to create
> a build-id dir. But till that time, dso_binary_type is not getting set yet.
> Hence, this patch introduced usage of dso->long_name to check if it is
> kallsyms. But based on the above review from Sashiko, it seems that this may
> create a security concern.
> 
> I tried to check for the possibility to set the dso binary type before
> dso__is_kallsyms gets called. But, I found that dso binary type is getting
> set based on dso__is_kallsyms only.
> 
> So, I am looking for suggestions/approach that we can take here.

Can we simply check with strcmp() for the whole string?

Thanks,
Namhyung