Re: [PATCH v5 03/11] perf tools: Try linked debug files for DSO debug info

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] perf tools: DEBUGLINK debuginfo resolution fails for containerized binaries
- [Medium] perf: Uninitialized stack read when parsing malformed .gnu_debuglink
--

commit 58954c9ee50dda18b6aba714c1a631c8845bc3e0
Author: Namhyung Kim <namhyung@kernel.org>

perf tools: Try linked debug files for DSO debug info

The dso__find_dbginfo_type() should try DSO_BINARY_TYPE__DEBUGLINK so it
can follow the .gnu_debuglink and find the debug information in the
separate file.

> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index df03f84c97235..913877b84b2d4 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
> @@ -2111,6 +2111,7 @@ void dso__find_dbginfo_type(struct dso *dso)
>  		DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO,
>  		DSO_BINARY_TYPE__BUILDID_DEBUGINFO,
>  		DSO_BINARY_TYPE__SYSTEM_PATH_DSO,
> +		DSO_BINARY_TYPE__DEBUGLINK,

[Severity: Medium]
Will this break debuginfo resolution for containerized binaries?

When DSO_BINARY_TYPE__DEBUGLINK is attempted, dso__get_filename() calls
dso__read_binary_type_filename(). That function performs an early check
on the host namespace:

tools/perf/util/dso.c:dso__read_binary_type_filename() {
	...
		if (!is_regular_file(filename)) {
			ret = -1;
			break;
		}
	...
}

If the binary is inside a mount namespace, is_regular_file() fails and
returns -1. This causes dso__get_filename() to abort early:

tools/perf/util/dso.c:dso__get_filename() {
	...
	if (dso__read_binary_type_filename(dso, type, root_dir, name, PATH_MAX))
		goto out;
	...
}

Will this bypass the subsequent dso__filename_with_chroot() fallback logic,
causing the tool to miss debuginfo for containerized applications?


[Severity: Medium]
Could this lead to an uninitialized stack read with malformed ELF files?

When resolving DSO_BINARY_TYPE__DEBUGLINK, dso__read_binary_type_filename()
allocates an uninitialized stack buffer:

tools/perf/util/dso.c:dso__read_binary_type_filename() {
	...
		char symfile[PATH_MAX];
		...
		ret = filename__read_debuglink(filename, symfile, PATH_MAX);
	...
}

If libbfd handles the read, it copies the section directly:

tools/perf/util/libbfd.c:libbfd_filename__read_debuglink() {
	...
	if (!bfd_get_section_contents(abfd, section, debuglink, 0,
				      section->size))
		goto out_close;
	...
}

Since BFD does not append a null terminator, if the .gnu_debuglink section
is malformed and lacks a null byte, could the subsequent snprintf() in
dso__read_binary_type_filename() read uninitialized stack memory?

>  		DSO_BINARY_TYPE__NOT_FOUND,
>  	};
>  	const enum dso_binary_type *type;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013172155.160869-1-namhyung@kernel.org?part=3