Re: [PATCH v4 3/9] perf disasm: Fix potential NULL pointer dereference in arch__find()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Fixing the NULL pointer dereference unmasks a reachable Use-After-Free in `arch__find()` when `arch_new_fn[]` fails, as the error path frees the `tmp` array but leaves the static `archs` pointer dangling.
--

--- Patch [3]: [PATCH v4 3/9] perf disasm: Fix potential NULL pointer dereference in arch__find() ---
commit 709c36ab73e377d0cda7f8eb4df8b0ebdb9717c8
Author: Ian Rogers <irogers@google.com>

perf disasm: Fix potential NULL pointer dereference in arch__find()

This commit fixes a NULL pointer dereference in the error path of
arch__find(). It resolves a segmentation fault that occurs when
arch_new_fn[] returns NULL by printing the numeric e_machine value
instead of attempting to access result->name.

Closes: https://lore.kernel.org/linux-perf-users/20260709035721.9EE901F000E9@smtp.kernel.org/

> diff --git a/tools/perf/util/disasm.c b/tools/perf/util/disasm.c
> index 0a1a7e9cf3efe..5b114f089d560 100644
> --- a/tools/perf/util/disasm.c
> +++ b/tools/perf/util/disasm.c
> @@ -182,8 +182,8 @@ const struct arch *arch__find(uint16_t e_machine, uint32_t e_flags, const char *
>  
>  	result = arch_new_fn[e_machine](&key, cpuid);
>  	if (!result) {
> -		pr_err("%s: failed to initialize %s (%u) arch priv area\n",
> -			__func__, result->name, e_machine);
> +		pr_err("%s: failed to initialize %u arch priv area\n",
> +			__func__, e_machine);
>  		free(tmp);

[Severity: High]
Will this error path leave the static global archs pointer dangling?

Earlier in arch__find(), tmp is allocated via:
tmp = reallocarray(archs, num_archs + 1, sizeof(*archs));

If reallocarray() moves the memory block, the old memory pointed to by archs
is freed. If arch_new_fn() then fails, this error path calls free(tmp).
Because archs is only updated on success later in the function, it will
remain pointing to freed memory.

Now that the NULL pointer dereference crash is fixed, execution can successfully
return from this error path. If num_archs > 0, wouldn't a subsequent call to
arch__find() pass the dangling archs pointer into bsearch(), causing a
use-after-free?

>  		return NULL;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710024952.1668911-1-irogers@google.com?part=3