All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Alireza Haghdoost" <haghdoost@uber.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 3/4] perf script: Add --lazy-load-symbols for lazy symbol loading
Date: Tue, 15 Sep 2026 18:54:29 +0000	[thread overview]
Message-ID: <20260915185430.B345F1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260915-perf-symbol-memory-send-v1-3-1d3360e21f07@uber.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf: memory exhaustion in ondemand_read_name() via truncated ELF
--

commit 9189c705674e1061e4de963daab5ec07bd55d920
Author: Alireza Haghdoost <haghdoost@uber.com>

perf script: Add --lazy-load-symbols for lazy symbol loading

This commit introduces lazy symbol loading for userspace ELF DSOs in perf
script. It builds a sorted in-memory index of symbols and resolves them via
binary search, reading symbol names on-demand from the string table using
pread() to reduce memory footprint.

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 914e42d21f70f..e4d77e46e8830 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c

[ ... ]

> +static const char *ondemand_read_name(int fd, u64 strtab_offset,
> +				      u64 strtab_size, u64 name_off,
> +				      char *buf, size_t buflen,
> +				      char **to_free)
> +{

[ ... ]

> +	/*
> +	 * Slow path: the name is longer than buflen.  Grow a heap buffer
> +	 * geometrically, doubling until the terminator appears, so a long
> +	 * name costs O(name length), not O(remaining strtab size).
> +	 */
> +	cap = 4096;
> +	for (;;) {
> +		char *tmp;
> +		size_t want = cap;
> +
> +		if (want > remain)
> +			want = remain;
> +		if (want == 0)
> +			break;
> +
> +		tmp = *to_free ? realloc(*to_free, want + 1) : malloc(want + 1);
> +		if (!tmp) {
> +			free(*to_free);
> +			*to_free = NULL;
> +			return NULL;
> +		}
> +		*to_free = tmp;
> +
> +		n = pread(fd, *to_free, want, file_off);
> +		if (n <= 0) {
> +			free(*to_free);
> +			*to_free = NULL;
> +			return NULL;
> +		}
> +		(*to_free)[n] = '\0';
> +
> +		if (memchr(*to_free, '\0', n))
> +			return *to_free;
> +
> +		/*
> +		 * Read the whole remaining strtab (or hit EOF) with no
> +		 * terminator: corrupt file, bail instead of re-reading.
> +		 */
> +		if (want >= remain || (u64)n >= remain)
> +			break;

[Severity: Medium]
Does this loop properly handle a short read (EOF) on a truncated ELF file?

If pread() hits EOF before filling the requested want bytes, n will be smaller
than want but greater than 0. The loop condition currently checks if
want >= remain or (u64)n >= remain, but it appears to miss an explicit
short-read/EOF check like (size_t)n < want.

Because of this, if remain is very large (based on an unvalidated sh_size
in the ELF header), the loop could continuously geometrically reallocate up
to remain bytes while reading the exact same short bytes from the constant
file_off. Could this cause memory exhaustion / an OOM allocation failure?

> +
> +		/* Avoid size_t overflow on absurdly large strtabs. */
> +		if (cap > SIZE_MAX / 2)
> +			break;
> +		cap *= 2;
> +	}
> +
> +	free(*to_free);
> +	*to_free = NULL;
> +	return NULL;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-perf-symbol-memory-send-v1-0-1d3360e21f07@uber.com?part=3

  reply	other threads:[~2026-09-15 18:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 18:42 [PATCH 0/4] perf script: Bounded and lazy symbol loading Alireza Haghdoost via B4 Relay
2026-09-15 18:42 ` Alireza Haghdoost
2026-09-15 18:42 ` [PATCH 1/4] perf symbols: Fix broken ELF_C_READ_MMAP fallback guard Alireza Haghdoost via B4 Relay
2026-09-15 18:42   ` Alireza Haghdoost
2026-09-15 18:53   ` sashiko-bot
2026-09-15 19:04     ` Alireza Haghdoost
2026-09-17  0:30       ` Namhyung Kim
2026-09-15 18:42 ` [PATCH 2/4] perf script: Add --max-symbol-bytes to bound ELF symbol memory Alireza Haghdoost via B4 Relay
2026-09-15 18:42   ` Alireza Haghdoost
2026-09-15 19:01   ` sashiko-bot
2026-09-16 16:15     ` Alireza Haghdoost
2026-09-17  6:53   ` Namhyung Kim
2026-09-19 18:37     ` Alireza Haghdoost
2026-09-15 18:42 ` [PATCH 3/4] perf script: Add --lazy-load-symbols for lazy symbol loading Alireza Haghdoost via B4 Relay
2026-09-15 18:42   ` Alireza Haghdoost
2026-09-15 18:54   ` sashiko-bot [this message]
2026-09-16 16:18     ` Alireza Haghdoost
2026-09-17  7:24   ` Namhyung Kim
2026-09-19 23:22     ` Alireza Haghdoost
2026-09-15 18:42 ` [PATCH 4/4] perf script: Document and test --lazy-load-symbols and --max-symbol-bytes Alireza Haghdoost via B4 Relay
2026-09-15 18:42   ` Alireza Haghdoost
2026-09-15 18:50   ` sashiko-bot
2026-09-16 16:21     ` Alireza Haghdoost

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=20260915185430.B345F1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=haghdoost@uber.com \
    --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.