Re: [PATCH 03/11] perf tools: Use perf_env__get_cpu_topology() in machine__resolve()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The bounds check on `al->cpu` fails to prevent 16-bit integer truncation when `env->nr_cpus_avail` exceeds 32767, breaking topology resolution and bypassing the patch's stated fix.
--

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

perf tools: Use perf_env__get_cpu_topology() in machine__resolve()

This commit fixes an out-of-bounds heap read in machine__resolve() when a
perf.data sample contains a large CPU index. It replaces the unsafe array
access with perf_env__get_cpu_topology(), which performs bounds and NULL
validation. A bounds check is also added to attempt to prevent 16-bit integer
truncation during the cast to struct perf_cpu.

> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 66f4843bb235d..ea75816d126a1 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
[ ... ]
> @@ -836,8 +837,18 @@ int machine__resolve(struct machine *machine, struct addr_location *al,
>  	if (al->cpu >= 0) {
>  		struct perf_env *env = machine->env;
>  
> -		if (env && env->cpu)
> -			al->socket = env->cpu[al->cpu].socket_id;
> +		/*
> +		 * Bounds-check al->cpu (s32) before casting to struct perf_cpu
> +		 * (int16_t): without this, e.g. 65536 truncates to 0 and silently
> +		 * returns CPU 0's topology.  Can go once perf_cpu.cpu is widened.
> +		 */
> +		if (env && al->cpu < env->nr_cpus_avail) {
> +			struct cpu_topology_map *topo;
> +
> +			topo = perf_env__get_cpu_topology(env, (struct perf_cpu){ al->cpu });

[Severity: Medium]
Does this bounds check prevent truncation if env->nr_cpus_avail exceeds 32767?

If a perf.data file specifies a large nr_cpus_avail (for instance, 
process_nrcpus() bounds it to 1,048,576), could a malicious al->cpu of 65536 
still pass this check? If so, wouldn't it cast to int16_t as 0 and silently
return CPU 0's topology, bypassing the fix?

Additionally, does this break valid topology resolution for CPUs >= 32768? A
valid al->cpu of 32768 would truncate to -32768, causing 
perf_env__get_cpu_topology() to return NULL since it verifies cpu >= 0.

> +			if (topo)
> +				al->socket = topo->socket_id;
> +		}
>  	}
>

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