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] Silent truncation of a 32-bit CPU index (`al->cpu`) down to a 16-bit `struct perf_cpu` bypasses intended bounds validation for malformed inputs.
--

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

perf tools: Use perf_env__get_cpu_topology() in machine__resolve()

This commit updates machine__resolve() to use perf_env__get_cpu_topology(),
replacing direct array access to prevent out-of-bounds heap reads from
untrusted perf.data samples.

> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c

[ ... ]

> @@ -835,9 +836,13 @@ int machine__resolve(struct machine *machine, struct addr_location *al,
>  
>  	if (al->cpu >= 0) {
>  		struct perf_env *env = machine->env;
> +		struct cpu_topology_map *topo;
>  
> -		if (env && env->cpu)
> -			al->socket = env->cpu[al->cpu].socket_id;
> +		if (env) {
> +			topo = perf_env__get_cpu_topology(env, (struct perf_cpu){ al->cpu });

[Severity: Medium]
Does this cast silently truncate the 32-bit al->cpu?

Since al->cpu is an s32 from the untrusted sample, and struct perf_cpu uses a
16-bit integer for the cpu index, an attacker providing an index like 65536
would truncate it to 0. Wouldn't this bypass the downstream bounds validation
and falsely associate the sample with CPU 0's topology?

Also, for systems with more than 32,767 CPUs, wouldn't this wrap to a
negative number and incorrectly fail the bounds check?

> +			if (topo)
> +				al->socket = topo->socket_id;
> +		}
>  	}
>  
>  	/* Account for possible out-of-order switch events. */

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