Re: [PATCH v8 3/3] perf tools gtk: fix two hierarchy-view stack buffer overflows

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Potential stack buffer overflow when writing to `col_types` array if `nr_cols` exceeds `MAX_COLUMNS`.
--

commit d31e2f191655501641db6dac561539e4edaedb03
Author: Matt Turner <mattst88@gmail.com>

perf tools gtk: fix two hierarchy-view stack buffer overflows

This commit fixes two stack buffer overflows in the perf GTK hierarchy view.
It tracks the write offset and uses scnprintf() to prevent buffer overflows
when building merged column headers. It also clamps the value passed to
advance_hpp() to prevent size underflows during entry formatting.

> diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
> index 716dcf02bd0e8..80df3fec8ea13 100644
> --- a/tools/perf/ui/gtk/hists.c
> +++ b/tools/perf/ui/gtk/hists.c

[ ... ]

> @@ -505,6 +516,7 @@ static void perf_gtk__show_hierarchy(GtkWidget *window, struct hists *hists,
>  	GtkWidget *view;
>  	int col_idx;
>  	int nr_cols = 0;
> +	int ret;
>  	char s[512];
>  	char buf[512];
>  	bool first_node, first_col;

[Severity: High]
This is a pre-existing issue, but while looking at
perf_gtk__show_hierarchy(), can this code overflow the col_types[] array?

Further down in perf_gtk__show_hierarchy(), the code does:

	hists__for_each_format(hists, fmt) {
		if (perf_hpp__is_sort_entry(fmt) ||
		    perf_hpp__is_dynamic_entry(fmt))
			break;

		col_types[nr_cols++] = G_TYPE_STRING;
	}
	col_types[nr_cols++] = G_TYPE_STRING;

Since col_types is declared as GType col_types[MAX_COLUMNS], if a
perf.data file defines a large number of overhead formats (for example,
from an event group with >= 32 events), could nr_cols exceed MAX_COLUMNS
and write past the end of the stack buffer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908-perf-gtk2-v8-0-e90d5d155f0d@gmail.com?part=3