From: Namhyung Kim <namhyung@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: Tengda Wu <wutengda@huaweicloud.com>, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v5 01/26] perf capstone: Symbolize address operands to match objdump on arm64
Date: Wed, 9 Sep 2026 10:49:04 -0400 [thread overview]
Message-ID: <aqFx4Fia3SWTrVZu@google.com> (raw)
In-Reply-To: <20260908131804.76F941F00A3A@smtp.kernel.org>
Hello,
On Tue, Sep 08, 2026 at 01:18:03PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Premature `map__put()` of `found_map` before the caller consumes `sym_name` creates a Use-After-Free vulnerability.
> --
>
> commit ff403b9f1717375044e9b6fbb3f09210431e386b
> Author: Tengda Wu <wutengda@huaweicloud.com>
> perf capstone: Symbolize address operands to match objdump on arm64
>
> This commit extends Capstone disassembly support on arm64 to resolve target
> addresses to symbols. It detects instructions with address operands, maps
> them to symbols, and formats the output to match objdump's style.
>
> > diff --git a/tools/perf/util/capstone.c b/tools/perf/util/capstone.c
> > index 74213daf87862..7f82c33e3464a 100644
> > --- a/tools/perf/util/capstone.c
> > +++ b/tools/perf/util/capstone.c
> [ ... ]
> > @@ -292,16 +303,44 @@ ssize_t capstone__fprintf_insn_asm(struct machine *machine, struct thread *threa
> > return printed;
> > }
> >
> > +static int resolve_symbol_from_addr(struct map *map, u64 addr,
> > + const char **sym_name, u64 *sym_offset)
> > +{
> > + struct map *found_map = NULL;
> > + struct symbol *sym;
> > + u64 al_addr;
> > + u64 ip = map__objdump_2mem(map, addr);
> > +
> > + if (dso__kernel(map__dso(map))) {
> > + /*
> > + * The kernel maps can be split into sections, let's
> > + * find the map first and then search the symbol.
> > + */
> > + found_map = maps__find(map__kmaps(map), ip);
> > + if (found_map == NULL)
> > + return -1;
> > + map = found_map;
> > + }
> > +
> > + /* convert it to map-relative address for search */
> > + al_addr = map__map_ip(map, ip);
> > +
> > + sym = map__find_symbol(map, al_addr);
> > + map__put(found_map);
> > +
> > + if (sym == NULL)
> > + return -1;
> > +
> > + *sym_name = sym->name;
> > + *sym_offset = al_addr - sym->start;
> > + return 0;
> > +}
>
> [Severity: Medium]
> Is map__put(found_map) called prematurely here? If the map is concurrently
> removed and the refcount drops to zero, the map and its symbols could be
> freed. Does this leave sym->name pointing to freed memory when it is assigned
> to *sym_name and returned to the caller?
Right, probably better to return a pointer to symbol instead and make
the found_map as an out parameter.
Thanks,
Namhyung
>
> > +
> > static void print_capstone_detail(struct cs_insn *insn, char *buf, size_t len,
> > struct annotate_args *args, u64 addr)
> > {
> [ ... ]
> > @@ -320,40 +360,114 @@ static void print_capstone_detail(struct cs_insn *insn, char *buf, size_t len,
> >
> > /* get the target address */
> > orig_addr = addr + insn->size + op->mem.disp;
> > - addr = map__objdump_2mem(map, orig_addr);
> > -
> > - if (dso__kernel(map__dso(map))) {
> > - /*
> > - * The kernel maps can be split into sections, let's
> > - * find the map first and then search the symbol.
> > - */
> > - found_map = maps__find(map__kmaps(map), addr);
> > - if (found_map == NULL)
> > - continue;
> > - map = found_map;
> > - }
> > -
> > - /* convert it to map-relative address for search */
> > - addr = map__map_ip(map, addr);
> > -
> > - sym = map__find_symbol(map, addr);
> > - if (sym == NULL) {
> > - map__put(found_map);
> > + if (resolve_symbol_from_addr(map, orig_addr, &sym_name, &sym_offset))
> > continue;
> > - }
> >
> > - if (addr == sym->start) {
> > + if (sym_offset == 0) {
> > scnprintf(buf, len, "\t# %"PRIx64" <%s>",
> > - orig_addr, sym->name);
> > + orig_addr, sym_name);
>
> [Severity: Medium]
> Can this result in a Use-After-Free? If resolve_symbol_from_addr() drops the
> map reference too early, sym_name might point to freed memory by the time it
> is dereferenced here in scnprintf().
>
> > } else {
> > scnprintf(buf, len, "\t# %"PRIx64" <%s+%#"PRIx64">",
> > - orig_addr, sym->name, addr - sym->start);
> > + orig_addr, sym_name, sym_offset);
> > }
> [ ... ]
> > +static void format_capstone_insn_arm64(struct cs_insn *insn, char *buf,
> > + size_t len, struct annotate_args *args)
> > +{
> > + struct map *map = args->ms->map;
> > + char *last_imm, *endptr;
> > + u64 addr;
> > +
> > + print_default_format(insn, buf, len);
> > + /*
> > + * Adjust instructions to keep the existing behavior with objdump.
> > + *
> > + * Example conversion:
> > + * From: b #0xffff8000800114c8
> > + * To: b ffff8000800114c8 <el0t_64_sync+0x108>
> > + */
> > + if (needs_symbolic_address(insn)) {
> > + const char *sym_name = NULL;
> > + u64 sym_offset;
> > +
> > + /* Extract last immediate value as address */
> > + last_imm = strrchr(buf, '#');
> > + if (!last_imm)
> > + return;
> > +
> > + addr = strtoull(last_imm + 1, &endptr, 16);
> > + if (endptr == last_imm + 1)
> > + return;
> > +
> > + if (resolve_symbol_from_addr(map, addr, &sym_name, &sym_offset))
> > + return;
> > +
> > + /* Symbolize the resolved address */
> > + len = len - (last_imm - buf);
> > + if (sym_offset == 0) {
> > + scnprintf(last_imm, len, "%"PRIx64" <%s>",
> > + addr, sym_name);
>
> [Severity: Medium]
> Does this also dereference the potentially dangling sym_name pointer if the
> underlying map was freed in resolve_symbol_from_addr()?
>
> > + } else {
> > + scnprintf(last_imm, len, "%"PRIx64" <%s+%#"PRIx64">",
> > + addr, sym_name, sym_offset);
> > + }
> > + }
> > +}
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788872630.git.wutengda@huaweicloud.com?part=1
next prev parent reply other threads:[~2026-09-09 14:49 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 13:05 [PATCH v5 00/26] perf arm64: Support data type profiling Tengda Wu
2026-09-08 13:05 ` [PATCH v5 01/26] perf capstone: Symbolize address operands to match objdump on arm64 Tengda Wu
2026-09-08 13:18 ` sashiko-bot
2026-09-09 14:49 ` Namhyung Kim [this message]
2026-09-10 7:38 ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 02/26] perf llvm: Fix arm64 adrp instruction disassembly mismatch with objdump Tengda Wu
2026-09-08 13:16 ` sashiko-bot
2026-09-09 14:50 ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 03/26] perf annotate-arm64: Generalize arm64_mov__parse to support more instructions Tengda Wu
2026-09-08 13:15 ` sashiko-bot
2026-09-09 14:52 ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 04/26] perf annotate-arm64: Handle load and store instructions Tengda Wu
2026-09-08 13:15 ` sashiko-bot
2026-09-09 14:58 ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 05/26] perf annotate: Normalize arch__dwarf_regnum() error return values Tengda Wu
2026-09-08 13:24 ` sashiko-bot
2026-09-08 17:57 ` Ian Rogers
2026-09-09 15:00 ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 06/26] perf annotate: Introduce extract_op_location callback for arch-specific parsing Tengda Wu
2026-09-08 13:20 ` sashiko-bot
2026-09-09 15:01 ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 07/26] perf dwarf-regs: Adapt get_dwarf_regnum() for arm64 Tengda Wu
2026-09-08 13:21 ` sashiko-bot
2026-09-09 15:03 ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 08/26] perf annotate: Adapt arch__dwarf_regnum() " Tengda Wu
2026-09-08 13:15 ` sashiko-bot
2026-09-09 15:04 ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 09/26] perf annotate-arm64: Implement extract_op_location() callback Tengda Wu
2026-09-08 13:18 ` sashiko-bot
2026-09-10 8:49 ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 10/26] perf annotate: Default to --itrace=i1i for data type profiling Tengda Wu
2026-09-08 13:15 ` sashiko-bot
2026-09-09 15:38 ` Adrian Hunter
2026-09-08 13:05 ` [PATCH v5 11/26] perf arm-spe: Set default synthesized event period to 1 Tengda Wu
2026-09-08 13:12 ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 12/26] perf annotate-data: Extract invalidate_reg_state() as a common helper Tengda Wu
2026-09-08 13:11 ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 13/26] perf annotate-arm64: Enable instruction tracking support Tengda Wu
2026-09-08 13:18 ` sashiko-bot
2026-09-10 9:20 ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 14/26] perf annotate-data: Add arch_get_reg_offset helper Tengda Wu
2026-09-08 13:22 ` sashiko-bot
2026-09-10 12:13 ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 15/26] perf annotate-arm64: Track return type after call instructions Tengda Wu
2026-09-08 13:14 ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 16/26] perf annotate-arm64: Support load instruction tracking Tengda Wu
2026-09-08 13:23 ` sashiko-bot
2026-09-10 13:19 ` Tengda Wu
2026-09-10 13:28 ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 17/26] perf annotate-arm64: Support store " Tengda Wu
2026-09-08 13:22 ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 18/26] perf annotate-data: Expand type_state_reg imm_value to u64 Tengda Wu
2026-09-08 13:26 ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 19/26] perf annotate-data: Track imm_value for stack variables Tengda Wu
2026-09-08 13:29 ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 20/26] perf annotate-x86: Delete stale stack state on store of untracked register Tengda Wu
2026-09-08 13:20 ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 21/26] perf annotate-arm64: Support stack variable tracking Tengda Wu
2026-09-08 13:36 ` sashiko-bot
2026-09-11 1:41 ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 22/26] perf annotate-arm64: Support 'mov' instruction tracking Tengda Wu
2026-09-08 13:27 ` sashiko-bot
2026-09-11 2:22 ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 23/26] perf annotate-arm64: Support 'add' " Tengda Wu
2026-09-08 13:27 ` sashiko-bot
2026-09-11 2:29 ` Tengda Wu
2026-09-08 13:06 ` [PATCH v5 24/26] perf annotate-arm64: Support 'adrp' instruction to track global variables Tengda Wu
2026-09-08 13:26 ` sashiko-bot
2026-09-08 13:06 ` [PATCH v5 25/26] perf annotate-arm64: Support per-cpu variable access tracking Tengda Wu
2026-09-08 13:30 ` sashiko-bot
2026-09-11 10:15 ` Tengda Wu
2026-09-08 13:06 ` [PATCH v5 26/26] perf annotate-arm64: Support 'mrs' instruction to track 'current' pointer Tengda Wu
2026-09-08 13:31 ` sashiko-bot
-- strict thread matches above, loose matches on Subject: below --
2026-09-08 13:00 [PATCH v5 00/26] perf arm64: Support data type profiling Tengda Wu
2026-09-08 13:00 ` [PATCH v5 01/26] perf capstone: Symbolize address operands to match objdump on arm64 Tengda Wu
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=aqFx4Fia3SWTrVZu@google.com \
--to=namhyung@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wutengda@huaweicloud.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.