Re: [PATCH 05/13] perf dso: Set error code when open() fails on uncompressed fallback path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Negative custom error codes leak into standard errno and cause __open_dso() to compute a positive fake file descriptor.
--

commit d095129ae47ce61267962a75bfe2602fe1eafe44
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf dso: Set error code when open() fails on uncompressed fallback path

This commit sets the error code when open() fails on the uncompressed
fallback path in filename__decompress(). It ensures the caller chain
correctly reads the populated errno instead of a stale or zero value.

> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index 511921bd901d8..1a2fc6d18da74 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
> @@ -344,9 +344,12 @@ int filename__decompress(const char *name, char *pathname,
>  	 * descriptor to the uncompressed file.
>  	 */
>  	if (!compressions[comp].is_compressed(name)) {
> +		fd = open(name, O_RDONLY | O_CLOEXEC);
> +		if (fd < 0)
> +			*err = errno;
>  		if (pathname && len > 0)
>  			pathname[0] = '\0';
> -		return open(name, O_RDONLY | O_CLOEXEC);
> +		return fd;
>  	}
>  
>  	fd = mkostemp(tmpbuf, O_CLOEXEC);

[Severity: High]
This isn't a bug introduced by this patch, but the commit message mentions
matching the error handling on the compressed path. Does that compressed
path have an issue where negative custom error codes leak into standard
errno?

If filename__decompress() sets *err to the custom enum value
DSO_LOAD_ERRNO__DECOMPRESSION_FAILURE (which is negative),
dso__get_filename() assigns this directly into standard errno:

tools/perf/util/dso.c:dso__get_filename() {
    ...
    errno = *dso__load_errno(dso);
    ...
}

Then __open_dso() handles the failure by calculating fd = -errno:

tools/perf/util/dso.c:__open_dso() {
    ...
    fd = -errno;
    ...
}

Could this double-negate the custom error code into a positive file
descriptor value (like 9996)?

If open_dso() then incorrectly believes it successfully opened the DSO
because fd >= 0, could it cache this as the active file descriptor?
This might cause close_data_fd() to later close an arbitrary file
descriptor used by another subsystem when perf cleans up.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612222413.40791-1-acme@kernel.org?part=5