Re: [PATCH v5 06/11] perf symbol: Get rid of machine_or_dso_e_machine()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf symbol: NULL pointer dereference in dso__load() on error path
--

commit a7899d8622f5885c1647a9ddbd7a9ae67999aeeb
Author: Namhyung Kim <namhyung@kernel.org>

perf symbol: Get rid of machine_or_dso_e_machine()

This commit removes the machine_or_dso_e_machine() fallback logic and relies
directly on perf_env__e_machine() for kernel maps. It aims to prevent
recursive locking issues and assumes kernel DSO architectures are correctly
described by the machine environment.

> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 56b8d75966133..a7afecb5816c2 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
[ ... ]
> @@ -1855,7 +1838,7 @@ int dso__load(struct dso *dso, struct map *map)
>  			ret = dso__load_guest_kernel_sym(dso, map);
>  
>  		machine = maps__machine(map__kmaps(map));
> -		if (machine && machine_or_dso_e_machine(machine, dso) == EM_X86_64)
> +		if (perf_env__e_machine(machine->env, /*e_flags=*/NULL) == EM_X86_64)

[Severity: Medium]
Does this code cause a NULL pointer dereference if machine is NULL?

By removing the machine pointer guard, if map__kmaps() returns NULL (for
example, if a kernel DSO is incorrectly associated with a non-kernel map from a
malformed perf.data file), maps__machine() will also return NULL. Passing
machine->env directly to perf_env__e_machine() in this state will then trigger
a segfault.

Could the machine check be restored before attempting to read its environment?

>  			machine__map_x86_64_entry_trampolines(machine, dso);
>  		goto out;
>  	}

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