All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Arnaldo Carvalho de Melo" <acme@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 6/8] perf header: Do validation of perf.data HEADER_CPU_DOMAIN_INFO
Date: Wed, 08 Apr 2026 18:28:49 +0000	[thread overview]
Message-ID: <20260408182850.DC446C2BC9E@smtp.kernel.org> (raw)
In-Reply-To: <20260408173203.96700-7-acme@kernel.org>

Sashiko AI review found 1 potential issue(s):
- [High] Lack of validation for `nr_domains` causes out-of-bounds reads and arbitrary frees during the cleanup path.
--

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

perf header: Do validation of perf.data HEADER_CPU_DOMAIN_INFO

This commit adds bounds checking for cpu and domain indices read from
a perf.data file's HEADER_CPU_DOMAIN_INFO section. It ensures these
values do not exceed nr_cpus_avail and max_sched_domains respectively.

> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c

[ ... ]

> @@ -3736,6 +3741,12 @@ static int process_cpu_domain_info(struct feat_fd *ff, void *data __maybe_unused
>  		cd_map[cpu]->cpu = cpu;
>  
>  		if (do_read_u32(ff, &nr_domains))
>  			return -1;
>  
>  		cd_map[cpu]->nr_domains = nr_domains;
>  
>  		cd_map[cpu]->domains = zalloc(sizeof(*d_info) * max_sched_domains);
>  		if (!cd_map[cpu]->domains)
>  			return -1;

Could there still be an issue with an unvalidated nr_domains value?

If a malformed file provides an nr_domains value much larger than
max_sched_domains, the loop below will eventually fail and return -1.

This triggers session teardown and calls free_cpu_domain_info(), which
iterates up to cd_map[i]->nr_domains and accesses cd_map[i]->domains[j].

Since the array size is only max_sched_domains, could this cause an
out-of-bounds read on the heap? If the out-of-bounds data is non-zero,
would it be treated as a pointer to struct domain_info and passed to
zfree(), causing arbitrary frees?

Also, if the domains array allocation fails here, cd_map[cpu]->domains is
NULL. Would the cleanup loop then blindly dereference a NULL pointer while
trying to access cd_map[i]->domains[j]?

>  
>  		for (j = 0; j < nr_domains; j++) {
>  			if (do_read_u32(ff, &domain))
>  				return -1;
>  
> +			if (domain >= max_sched_domains) {
> +				pr_err("Invalid HEADER_CPU_DOMAIN_INFO: domain %d >= max_sched_domains (%d)\n",
> +				       domain, max_sched_domains);
> +				return -1;
> +			}

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

  reply	other threads:[~2026-04-08 18:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 17:31 [PATCHES perf-tools-next v6 0/8] Cleanups and fixes Arnaldo Carvalho de Melo
2026-04-08 17:31 ` [PATCH 1/8] perf symbols: Make variable receiving result strrchr() const Arnaldo Carvalho de Melo
2026-04-08 17:31 ` [PATCH 2/8] perf util: Kill die() prototype, dead for a long time Arnaldo Carvalho de Melo
2026-04-08 17:31 ` [PATCH 3/8] perf tools: Make more global variables static Arnaldo Carvalho de Melo
2026-04-08 17:31 ` [PATCH 4/8] perf bench: Constify tables Arnaldo Carvalho de Melo
2026-04-08 17:32 ` [PATCH 5/8] perf header: Use a max number of command line args Arnaldo Carvalho de Melo
2026-04-08 18:09   ` sashiko-bot
2026-04-08 17:32 ` [PATCH 6/8] perf header: Do validation of perf.data HEADER_CPU_DOMAIN_INFO Arnaldo Carvalho de Melo
2026-04-08 18:28   ` sashiko-bot [this message]
2026-04-08 17:32 ` [PATCH 7/8] perf tools: Use calloc() where applicable Arnaldo Carvalho de Melo
2026-04-08 18:47   ` sashiko-bot
2026-04-08 17:32 ` [PATCH 8/8] perf tools: Replace basename() calls with perf_basename() Arnaldo Carvalho de Melo
2026-04-09  2:20 ` [PATCHES perf-tools-next v6 0/8] Cleanups and fixes Namhyung Kim
2026-04-09 10:33   ` Arnaldo Carvalho de Melo
2026-04-09 16:46 ` Namhyung Kim
  -- strict thread matches above, loose matches on Subject: below --
2026-04-08 17:28 [PATCHES perf-tools-next v5 0/7] " Arnaldo Carvalho de Melo
2026-04-08 17:28 ` [PATCH 6/8] perf header: Do validation of perf.data HEADER_CPU_DOMAIN_INFO Arnaldo Carvalho de Melo
2026-04-08 18:38   ` sashiko-bot

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=20260408182850.DC446C2BC9E@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=acme@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko@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.