Re: [PATCH 7/9] perf sched: Fix thread reference leak in idle hist processing

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Unchecked reallocarray failure leads to out-of-bounds array write.
--

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

perf sched: Fix thread reference leak in idle hist processing

This commit resolves a thread reference leak in timehist_sched_change_event()
by properly releasing the acquired thread reference using thread__zput() before
clearing the pointer during idle history processing.

> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
> index 4600d70b48610..c0cd3cbb602aa 100644
> --- a/tools/perf/builtin-sched.c
> +++ b/tools/perf/builtin-sched.c
> @@ -2940,7 +2940,7 @@ static int timehist_sched_change_event(const struct perf_tool *tool,
>  			if (itr->cursor.nr)
>  				callchain_append(&itr->callchain, &itr->cursor, t - tprev);
>  
> -			itr->last_thread = NULL;
> +			thread__zput(itr->last_thread);
>  		}
>  
>  		if (!sched->summary_only)

[Severity: Critical]
This isn't a bug introduced by this patch, but I noticed a potential
regression in a different file:
tools/perf/util/drm_pmu.c:for_each_drm_fdinfo_in_dir().

When expanding the minor device array:

		if (minors->minors_num == minors->minors_len) {
			unsigned int *tmp = reallocarray(minors->minors, minors->minors_len + 4,
							 sizeof(unsigned int));

			if (tmp) {
				minors->minors = tmp;
				minors->minors_len += 4;
			}
		}
		minors->minors[minors->minors_num++] = minor;

If reallocarray() fails (e.g., due to memory exhaustion), it returns a null
pointer and the array's capacity (minors_len) is not updated.

However, the code proceeds unconditionally to write the minor into
minors->minors[minors->minors_num++].

Could this cause a null pointer dereference on the first allocation failure?

Furthermore, because minors_num is incremented without minors_len
increasing, would subsequent loops bypass the minors_num == minors_len
check completely, leading to continuous and unbounded out-of-bounds heap
writes for each new file descriptor?

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