From: sashiko-bot@kernel.org
To: "Thomas Falcon" <thomas.falcon@intel.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 1/6] perf mem: Fix size tracking for mem_lvl's in perf_script__meminfo_scnprintf()
Date: Thu, 09 Jul 2026 22:28:33 +0000 [thread overview]
Message-ID: <20260709222834.004131F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260709221736.33446-2-thomas.falcon@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Cascading integer underflows and stack buffer overflows in `perf_script__meminfo_scnprintf` and its helper functions due to unbounded `strcat` and unchecked size arithmetic.
--
--- Patch [1]: [PATCH 1/6] perf mem: Fix size tracking for mem_lvl's in perf_script__meminfo_scnprintf() ---
commit e57d4daab871fa57aef1ac0569d81f8d93753398
Author: Thomas Falcon <thomas.falcon@intel.com>
perf mem: Fix size tracking for mem_lvl's in perf_script__meminfo_scnprintf()
When printing memory info in perf script, the entire size of the
buffer is passed to perf_mem__lvl_scnprintf() instead of the remaining
size. Pass the remaining buffer size instead.
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -610,7 +610,7 @@ int perf_script__meminfo_scnprintf(char *out, size_t sz, const struct mem_info *
> i += scnprintf(out, sz, "|OP ");
> i += perf_mem__op_scnprintf(out + i, sz - i, mem_info);
> i += scnprintf(out + i, sz - i, "|LVL ");
> - i += perf_mem__lvl_scnprintf(out + i, sz, mem_info);
> + i += perf_mem__lvl_scnprintf(out + i, sz - i, mem_info);
> i += scnprintf(out + i, sz - i, "|SNP ");
[Severity: Critical]
This is a pre-existing issue, but does sz - i risk underflowing here if i
exceeds sz?
Looking at the helper functions called here, they use strcat() without bounds
checking and advance the length manually:
tools/perf/util/mem-events.c:perf_mem__lvl_scnprintf() {
...
if (printed++) {
strcat(out, " or ");
l += 4;
}
l += scnprintf(out + l, sz - l, mem_lvl[i]);
...
}
If multiple bits are set and l exceeds sz due to the manual l += 4 increments,
could sz - l underflow to SIZE_MAX? This would cause subsequent scnprintf()
calls to write past the buffer boundaries. The same pattern appears to exist
in perf_mem__snp_scnprintf() and perf_mem__tlb_scnprintf().
Since these helpers can return a length greater than sz, the accumulated size i
in perf_script__meminfo_scnprintf() could also grow larger than sz. This would
cause cascading underflows when subtracting i from sz in subsequent calls.
Should we ensure the accumulated length is checked against sz before
subtraction, and consider replacing strcat() with a bounded string operation
in the helper functions?
> i += perf_mem__snp_scnprintf(out + i, sz - i, mem_info);
> i += scnprintf(out + i, sz - i, "|TLB ");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260709221736.33446-1-thomas.falcon@intel.com?part=1
next prev parent reply other threads:[~2026-07-09 22:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 22:17 [PATCH 0/6] perf: Add support for memory region/range reporting Thomas Falcon
2026-07-09 22:17 ` [PATCH 1/6] perf mem: Fix size tracking for mem_lvl's in perf_script__meminfo_scnprintf() Thomas Falcon
2026-07-09 22:28 ` sashiko-bot [this message]
2026-07-09 22:17 ` [PATCH 2/6] perf mem: Add support for printing PERF_MEM_LVLNUM_L0 Thomas Falcon
2026-07-09 22:17 ` [PATCH 3/6] perf tools: Show memory region in perf-c2c subcommand Thomas Falcon
2026-07-09 22:29 ` sashiko-bot
2026-07-09 22:17 ` [PATCH 4/6] perf tools: Show memory region in perf-script subcommand Thomas Falcon
2026-07-09 22:28 ` sashiko-bot
2026-07-09 22:17 ` [PATCH 5/6] perf header: Support memory ranges Thomas Falcon
2026-07-09 22:31 ` sashiko-bot
2026-07-09 22:17 ` [PATCH 6/6] perf c2c: print memory region data with stdio output Thomas Falcon
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=20260709222834.004131F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=thomas.falcon@intel.com \
/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.