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

[sashiko-bot@kernel.org]

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