Re: [PATCH v7 6/7] perf test: Remove perftool drivers

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [Critical] Out-of-bounds stack write in `append_script_to_suite` and `prepare_test_suite` when reading directory paths via `/proc/self/fd/`.
--

commit 1230f358b280e45e7854550cfac958f0de10d7ac
Author: Jakub Brnak <jbrnak@redhat.com>

perf test: Remove perftool drivers

The perf now provides all of the features required for running the
perftool test cases, such as creating log directories, running
setup scripts and the tests are structured by the base_ directories.

[ ... ]

> diff --git a/tools/perf/tests/tests-scripts.c b/tools/perf/tests/tests-scripts.c
> index fc5e1b835ecc3..a83e30ee4a099 100644
> --- a/tools/perf/tests/tests-scripts.c
> +++ b/tools/perf/tests/tests-scripts.c
> @@ -487,9 +487,6 @@ static void append_suites_in_dir(int dir_fd,
>  		if (!is_directory_fd(dir_fd, ent))
>  			continue;
>  
> -		if (strncmp(ent->d_name, "base_", 5) == 0)
> -			continue; /* Skip scripts that have a separate driver. */
> -

Since this patch exposes base_ directories to the parsing logic, can this
lead to an out-of-bounds stack write in append_script_to_suite() when reading
directory paths via /proc/self/fd/?

Looking at append_script_to_suite(), readlink() reads the directory path into
a stack buffer file_name[PATH_MAX]:

append_script_to_suite() {
	...
	char file_name[PATH_MAX], link[128];
	...
	len = readlink(link, file_name, sizeof(file_name));
	if (len < 0) {
		...
	}
	file_name[len++] = '/';
	strcpy(&file_name[len], name);
	...
}

readlink() does not null-terminate and returns up to the buffer size.

If the directory's absolute path length is PATH_MAX or greater, readlink()
returns PATH_MAX.

The subsequent code file_name[len++] = '/' then writes to file_name[PATH_MAX],
which is past the end of the array.

Does the following strcpy() overflow file_name[], causing a regression with
a stack buffer overflow?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260416111419.385010-1-jbrnak@redhat.com?part=6