All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Yujun Dong <yujundong@pascal-lab.net>, linux-perf-users@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf branch: Fix heap out-of-bounds write in branch_type_count()
Date: Mon, 11 Aug 2025 12:33:58 +0530	[thread overview]
Message-ID: <17bdc644-329a-42fb-aba2-d7f80f2a1037@arm.com> (raw)
In-Reply-To: <20250809093812.308027-1-yujundong@pascal-lab.net>



On 09/08/25 3:08 PM, Yujun Dong wrote:
> The branch_type_count() function writes to st->new_counts[flags->new_type]
> when flags->type is PERF_BR_EXTEND_ABI. However, while the array
> st->new_counts is sized for PERF_BR_NEW_MAX (8) entries, the field
> flags->new_type is a 4-bit unsigned value and may hold values up to 15.
> 
> This mismatch allows crafted perf data to trigger a heap out-of-bounds
> write when flags->new_type >= 8, leading to memory corruption.

Crafted ? How could flags->new_type >= 8 when PERF_BR_NEW_MAX is capped at 8.
Is this a real scenario that happened on a system ?

> 
> Add a bounds check to ensure flags->new_type is less than
> PERF_BR_NEW_MAX before accessing the new_counts array.

But it might make sense to add this check just to be on the safer side.

> 
> Fixes: 0ddea8e2a0c2 ("perf branch: Extend branch type classification")
> Signed-off-by: Yujun Dong <yujundong@pascal-lab.net>
> ---
>  tools/perf/util/branch.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/util/branch.c b/tools/perf/util/branch.c
> index 3712be067464..8ea6628c7735 100644
> --- a/tools/perf/util/branch.c
> +++ b/tools/perf/util/branch.c
> @@ -21,10 +21,12 @@ void branch_type_count(struct branch_type_stat *st, struct branch_flags *flags,
>  	if (flags->type == PERF_BR_UNKNOWN || from == 0)
>  		return;
>  
> -	if (flags->type == PERF_BR_EXTEND_ABI)
> -		st->new_counts[flags->new_type]++;
> -	else
> +	if (flags->type == PERF_BR_EXTEND_ABI) {
> +		if (flags->new_type < PERF_BR_NEW_MAX)
> +			st->new_counts[flags->new_type]++;
> +	} else {
>  		st->counts[flags->type]++;
> +	}
>  
>  	if (flags->type == PERF_BR_COND) {
>  		if (to > from)



       reply	other threads:[~2025-08-11  7:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250809093812.308027-1-yujundong@pascal-lab.net>
2025-08-11  7:03 ` Anshuman Khandual [this message]
2025-08-12  7:31   ` [PATCH] perf branch: Fix heap out-of-bounds write in branch_type_count() Yujun Dong
2025-08-13 14:20     ` Anshuman Khandual

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=17bdc644-329a-42fb-aba2-d7f80f2a1037@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=yujundong@pascal-lab.net \
    /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.