Re: [PATCH 06/11] perf sched: Fix idle-hist callchain display using wrong rb_first variant

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The bounds check in `machine__resolve` fails to prevent `s32 al->cpu` from truncating to `int16_t` for large CPU values, leading to silent topology resolution errors for systems with >= 32768 CPUs.
--

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

perf tools: Use perf_env__get_cpu_topology() in machine__resolve()

This commit modifies machine__resolve() to retrieve CPU socket IDs using
perf_env__get_cpu_topology() instead of direct array access. It adds a
bounds check against env->nr_cpus_avail to prevent out-of-bounds heap
reads before casting the CPU index to a 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]
Will this still truncate to int16_t if env->nr_cpus_avail is larger than 32767?

Since env->nr_cpus_avail can legally be up to 1,048,576, the check
al->cpu < env->nr_cpus_avail evaluates to true for CPU values like 65536.
When cast to struct perf_cpu, which wraps an int16_t, 65536 wraps to 0 and
silently fetches the topology for CPU 0 instead of the requested CPU.

For CPUs between 32768 and 65535, the cast results in a negative number,
causing perf_env__get_cpu_topology() to return NULL.

Prior to this patch, env->cpu[al->cpu] successfully handled large CPU indices.
Does this code introduce a functional regression on high-core-count systems
or when parsing perf.data files with a large nr_cpus_avail?

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

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