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

[Namhyung Kim <namhyung@kernel.org>]

On Tue, Oct 13, 2026 at 05:34:34PM +0000, sashiko-bot@kernel.org wrote:
> 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?

This is a known problem and I think it's in a broken state.  Let me
work on a fix after landing this series.

> 
> 
> [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?

This is a pre-existing issue.  Let's fix it separately.

Thanks,
Namhyung

> 
> >  		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