Re: [PATCH 01/11] perf tools: Fix get_max_num() size_t underflow on empty sysfs file

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Out-of-bounds write (buffer underflow) when reading empty files due to unvalidated length after string read operations.
--

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

perf tools: Fix get_max_num() size_t underflow on empty sysfs file

This commit prevents a size_t underflow in get_max_num() by adding an early
return when filename__read_str() yields an empty file with a length of 0.
This protects the subsequent code from scanning backward out of bounds.

> diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
> index 21fa781b03cc7..1fab00ec4a59a 100644
> --- a/tools/perf/util/cpumap.c
> +++ b/tools/perf/util/cpumap.c
> @@ -448,6 +448,12 @@ static int get_max_num(char *path, int *max)
>  
>  	buf[num] = '\0';
>  
> +	/* empty file — nothing to parse */
> +	if (num == 0) {
> +		err = -1;
> +		goto out;
> +	}
> +

[Severity: High]
This is a pre-existing issue, but since this patch successfully prevents an
underflow with empty files, could the exact same bug exist in other places 
that read system files?

For instance, in tools/perf/util/pmu.c:pmu_id():

    if (filename__read_str(path, &str, &len) < 0)
        ...
    str[len - 1] = 0; /* remove line feed */

If len is 0 due to an empty file, does len - 1 underflow to SIZE_MAX and
cause a 1-byte out-of-bounds write that corrupts heap chunk metadata?

A similar pattern appears in
tools/perf/util/thread.c:thread__set_comm_from_proc():

    if (procfs__read_str(path, &comm, &sz) < 0)
        ...
    comm[sz - 1] = '\0';

Could this also result in the same buffer underwrite if the /proc/.../comm
file happens to be empty?

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