Re: [PATCH 05/29] perf zstd: Fix multi-iteration decompression and error handling

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing O_NONBLOCK when opening potentially user-controlled file paths, which can hang the process.
--

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

perf zstd: Fix multi-iteration decompression and error handling
    
zstd_decompress_stream() has two bugs in its multi-iteration loop:
    
1. After each ZSTD_decompressStream() call, the code advances
   output.dst by output.pos but doesn't reset output.pos to 0.

[ ... ]

> diff --git a/tools/perf/util/zstd.c b/tools/perf/util/zstd.c
> index ecda9deb53b73..21a0eb58597c2 100644
> --- a/tools/perf/util/zstd.c
> +++ b/tools/perf/util/zstd.c
> @@ -123,14 +123,26 @@ size_t zstd_decompress_stream(struct zstd_data *data, void *src, size_t src_size
>  		}
>  	}
>  	while (input.pos < input.size) {

[Severity: High]
This isn't a bug introduced by this patch, but functions that extract build
IDs, such as filename__read_build_id() in tools/perf/util/symbol-elf.c and
sysfs__read_build_id() in tools/perf/util/symbol-minimal.c, open file paths
originating from user-controlled sources.

The underlying open(..., O_RDONLY) calls lack the O_NONBLOCK flag. Even though
checks like is_regular_file() exist in some places, they suffer from
Time-of-Check to Time-of-Use (TOCTOU) races.

If a path resolves to a blocking special file like a FIFO or a hung network
mount, the open() call will hang the process.

Could we add O_NONBLOCK to these open() calls?

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