Re: [PATCH 8/8] perf sched: Replace BUG_ON and add NULL checks in replay event helpers

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Heap buffer overflow in register_pid() due to unbounded strcpy() from untrusted input.
--

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

perf sched: Replace BUG_ON and add NULL checks in replay event helpers

This commit replaces BUG_ON() calls with graceful error handling and adds
missing NULL checks for memory allocations in the perf sched replay helpers.
It ensures the tool returns early instead of crashing when processing
untrusted perf.data input that triggers memory exhaustion.

>     get_new_event() has three issues:
>     
>     1. The zalloc() result is dereferenced without a NULL check, crashing
>        on allocation failure.
>     
>     2. BUG_ON(!task->atoms) kills the process when realloc() fails.
>        Since perf.data is untrusted input, this should be a graceful error.

[Severity: Critical]
This is a pre-existing issue, but since perf.data is treated as untrusted
input, does register_pid() have a heap buffer overflow?

When register_pid() allocates a new task_desc, it blindly copies the comm
parameter into a fixed-size buffer:

tools/perf/builtin-sched.c:register_pid() {
	...
	task = zalloc(sizeof(*task));
	task->pid = pid;
	task->nr = sched->nr_tasks;
	strcpy(task->comm, comm);
	...
}

If a crafted perf.data file supplies a trace event containing a comm
string significantly longer than the task->comm array (typically 16 bytes),
could this unbounded strcpy() overflow the buffer and overwrite subsequent
struct fields like nr_events or the atoms array pointer?

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