Re: [PATCH v2 06/16] perf data: Fix directory file descriptor leak in perf_data__switch

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The patch introduces a Use-After-Free during file rotation in directory mode. By changing `perf_data__switch()` to call `perf_data__close()`, the `data->dir.files` array is freed. However, thread mmaps (`map->file`) still retain pointers to this freed array and are never updated. Subsequent writes dereference the freed memory.
--

commit d39defbf0b046135d95bd01181c56fe40f6a6430
Author: Ian Rogers <irogers@google.com>

perf data: Fix directory file descriptor leak in perf_data__switch

This commit fixes a file descriptor leak in perf_data__switch() when running
in directory mode. It replaces perf_data_file__close() with perf_data__close()
to properly close thread-local directory files during file rotation.

> diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
> --- a/tools/perf/util/data.c
> +++ b/tools/perf/util/data.c
> @@ -472,8 +472,7 @@ int perf_data__switch(struct perf_data *data,
>  		pr_warning("Failed to rename %s to %s\n", data->path, *new_filepath);
>  
>  	if (!at_exit) {
> -		perf_data_file__close(&data->file);
> -		data->open = false;
> +		perf_data__close(data);

[Severity: Critical]
Could this cause a use-after-free regression during file rotation?

Calling perf_data__close(data) here frees the data->dir.files array.
However, thread mmaps (like map->file) appear to still retain pointers to this
freed memory and are not updated.

For example, in tools/perf/builtin-record.c:record__write():

    if (perf_data_file__write(file, bf, size) < 0) {

The file pointer here is aliased from map->file, which now points to the
freed memory. If someone runs perf record --switch-output with threads
enabled, the subsequent writes dereference these dangling pointers.

>  		ret = perf_data__open(data);
>  		if (ret < 0)
>  			goto out;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624051535.3584977-1-irogers@google.com?part=6