All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Athira Rajeev" <atrajeev@linux.ibm.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH V3] tools/perf: Fix the check for parameterized field in event term
Date: Sun, 26 Apr 2026 08:17:30 +0000	[thread overview]
Message-ID: <20260426081730.CA2D5C2BCB4@smtp.kernel.org> (raw)
In-Reply-To: <20260426080056.16558-1-atrajeev@linux.ibm.com>

Sashiko AI review found 1 potential issue(s):
- [High] Unconditional increment of `buf_used` causes unsigned integer underflow leading to a stack buffer overflow.
--

commit 105f365626ee620dbee6f08aafbe58eaca32755c
Author: Athira Rajeev <atrajeev@linux.ibm.com>

tools/perf: Fix the check for parameterized field in event term

This commit fixes the event term checking by changing strstr(alias->terms, "=?");
to !strstr(alias->terms, "=?"). It also replaces some snprintf calls with
scnprintf in buffer offset calculations to prevent out-of-bounds counting.

> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 23337d2fa281..ca0ceb0623ca 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c

[ ... ]

> @@ -2237,13 +2241,13 @@ int perf_pmu__for_each_event(struct perf_pmu *pmu, bool skip_duplicate_pmus,
>  		info.scale_unit = NULL;
>  		if (strlen(event->unit) || event->scale != 1.0) {
>  			info.scale_unit = buf + buf_used;
> -			buf_used += snprintf(buf + buf_used, sizeof(buf) - buf_used,
> +			buf_used += scnprintf(buf + buf_used, sizeof(buf) - buf_used,
>  					"%G%s", event->scale, event->unit) + 1;
>  		}

Can this unconditional + 1 addition to buf_used cause a regression by
triggering a stack buffer overflow in the subsequent scnprintf call?

buf is a local 1024-byte stack array, and buf_used tracks the offset as an
unsigned size_t. If format_alias() fills buf to its limit, strlen(buf) will
be 1023, causing buf_used to be initialized to 1024.

If the event has a scale or unit, the size parameter to scnprintf becomes
sizeof(buf) - buf_used, which evaluates to 1024 - 1024 = 0. scnprintf safely
writes nothing and returns 0.

However, buf_used += 0 + 1 unconditionally increments buf_used to 1025.

>  		info.desc = event->desc;
>  		info.long_desc = event->long_desc;
>  		info.encoding_desc = buf + buf_used;
> -		buf_used += snprintf(buf + buf_used, sizeof(buf) - buf_used,
> +		buf_used += scnprintf(buf + buf_used, sizeof(buf) - buf_used,
>  				"%.*s/%s/", (int)pmu_name_len, info.pmu_name, event->terms) + 1;

Does the size calculation sizeof(buf) - buf_used underflow here?

Since buf_used is now 1025, 1024 - 1025 underflows the size_t type to
SIZE_MAX. scnprintf would then be invoked with an effectively unbounded size
and an out-of-bounds pointer (buf + 1025), which could overwrite adjacent
memory on the stack.

Would it be better to bound the remaining space calculation and only increment
the offset if space actually existed, perhaps using sub_non_neg() like the
patch does earlier in format_alias()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260426080056.16558-1-atrajeev@linux.ibm.com?part=1

  reply	other threads:[~2026-04-26  8:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-26  8:00 [PATCH V3] tools/perf: Fix the check for parameterized field in event term Athira Rajeev
2026-04-26  8:17 ` sashiko-bot [this message]
2026-04-27  6:01 ` Namhyung Kim

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=20260426081730.CA2D5C2BCB4@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=atrajeev@linux.ibm.com \
    --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.