From: sashiko-bot@kernel.org
To: "Arnaldo Carvalho de Melo" <acme@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 5/5] perf sched: Fix register_pid() overflow, strcpy, and BUG_ON
Date: Fri, 05 Jun 2026 12:29:02 +0000 [thread overview]
Message-ID: <20260605122902.D32F21F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260605121515.1725549-6-acme@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Incomplete error rollback in register_pid() leads to state corruption, memory leaks, and deadlocks during replay.
Pre-existing issues:
- [High] Unhandled memory allocation failures and reachable BUG_ON() in get_new_event() and add_sched_event_wakeup() cause crashes on untrusted input.
--
commit ff8db8ecbe0e2e8aa902db3edce9b5b6e8db02f4
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON
This commit aims to fix several issues in register_pid() when processing
untrusted perf.data, including integer/heap overflows and BUG_ON calls on
allocation failures. It caps the PID, uses safe string copying, and handles
reallocation failures gracefully.
> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
> index 87a1f4cf8760e..21fb820b625b4 100644
> --- a/tools/perf/builtin-sched.c
> +++ b/tools/perf/builtin-sched.c
[ ... ]
> @@ -469,9 +481,11 @@ static struct task_desc *register_pid(struct perf_sched *sched,
> return task;
>
> task = zalloc(sizeof(*task));
> + if (task == NULL)
> + return NULL;
> task->pid = pid;
> - task->nr = sched->nr_tasks;
> - strcpy(task->comm, comm);
> + if (comm)
> + strlcpy(task->comm, comm, sizeof(task->comm));
> /*
> * every task starts in sleeping state - this gets ignored
> * if there's no wakeup pointing to this sleep state:
> */
> add_sched_event_sleep(sched, task, 0);
[Severity: High]
This is a pre-existing issue, but since the patch aims to prevent crashes on
memory exhaustion when parsing untrusted data, does this still leave a path
to crash?
register_pid() unconditionally calls add_sched_event_sleep(), which calls
get_new_event(). Inside get_new_event(), the result of zalloc() is used
without a NULL check, leading to an immediate dereference:
get_new_event()
{
...
struct sched_atom *event = zalloc(sizeof(*event));
...
event->timestamp = timestamp;
...
BUG_ON(!task->atoms);
}
There is also a remaining BUG_ON() upon realloc() failure.
Similarly, add_sched_event_wakeup() allocates wait_sem and passes it
unchecked to sem_init(), causing another crash if zalloc() fails:
add_sched_event_wakeup()
{
...
wakee_event->wait_sem = zalloc(sizeof(*wakee_event->wait_sem));
sem_init(wakee_event->wait_sem, 0, 0);
}
>
> sched->pid_to_task[pid] = task;
> - sched->nr_tasks++;
> - sched->tasks = realloc(sched->tasks, sched->nr_tasks * sizeof(struct task_desc *));
> - BUG_ON(!sched->tasks);
> - sched->tasks[task->nr] = task;
> + tasks_p = realloc(sched->tasks, (sched->nr_tasks + 1) * sizeof(struct task_desc *));
> + if (!tasks_p)
> + return NULL;
[Severity: High]
If realloc() fails here, does this leak the newly allocated task and leave
a corrupted state?
The task has already been assigned to sched->pid_to_task[pid] above. If we
return NULL, the caller gets an error, but the partially initialized task
remains in the pid_to_task array and is never added to sched->tasks.
If a caller like replay_fork_event() ignores the NULL return value:
replay_fork_event()
{
...
register_pid(sched, thread__tid(parent), thread__comm_str(parent));
register_pid(sched, thread__tid(child), thread__comm_str(child));
}
Subsequent events for the same PID will find the partially initialized task
in pid_to_task and successfully add events to it. Because the task is not in
sched->tasks, perf sched replay will fail to spawn a thread for it in
create_tasks(). When other simulated threads expect to be awoken by this
missing thread, they might wait indefinitely on a semaphore, deadlocking the
tool.
> + sched->tasks = tasks_p;
> + sched->tasks[sched->nr_tasks] = task;
> + task->nr = sched->nr_tasks++;
>
> if (verbose > 0)
> printf("registered task #%ld, PID %ld (%s)\n", sched->nr_tasks, pid, comm);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260605121515.1725549-1-acme@kernel.org?part=5
prev parent reply other threads:[~2026-06-05 12:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 12:15 [PATCHES v1 0/5] perf tools: Fix OOB reads, reference leaks, and overflow in sched/script/auxtrace Arnaldo Carvalho de Melo
2026-06-05 12:15 ` [PATCH 1/5] perf tools: Guard remaining test_bit calls from OOB sample CPU Arnaldo Carvalho de Melo
2026-06-05 12:31 ` sashiko-bot
2026-06-05 12:15 ` [PATCH 2/5] perf tools: Add bounds check to cpu__get_node() Arnaldo Carvalho de Melo
2026-06-05 14:30 ` sashiko-bot
2026-06-05 14:45 ` Arnaldo Carvalho de Melo
2026-06-05 12:15 ` [PATCH 3/5] perf sched: Fix thread reference leaks in timehist_get_thread() Arnaldo Carvalho de Melo
2026-06-05 12:35 ` sashiko-bot
2026-06-05 12:15 ` [PATCH 4/5] perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing Arnaldo Carvalho de Melo
2026-06-05 12:43 ` sashiko-bot
2026-06-05 14:34 ` David Ahern
2026-06-05 15:01 ` Arnaldo Carvalho de Melo
2026-06-05 12:15 ` [PATCH 5/5] perf sched: Fix register_pid() overflow, strcpy, and BUG_ON Arnaldo Carvalho de Melo
2026-06-05 12:29 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260605122902.D32F21F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=acme@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.