From: sashiko-bot@kernel.org
To: "Stian Halseth" <stian@itx.no>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf unwind-libdw: Fix reading the stack of a 32-bit task
Date: Wed, 23 Sep 2026 19:45:34 +0000 [thread overview]
Message-ID: <20260923194534.C89B71F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260923193432.2489729-1-stian@itx.no>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] perf: incorrect data extraction for unaligned stack reads during cross-endian unwinding
--
commit c969a9ae6966b9f317efd438b881a5fa16635c84
Author: Stian Halseth <stian@itx.no>
perf unwind-libdw: Fix reading the stack of a 32-bit task
This commit fixes reading the stack of a 32-bit task during unwinding on
big-endian machines by reading 4 bytes instead of 8, preventing traps. It
also corrects word ordering for cross-endian unwinding.
> diff --git a/tools/perf/util/unwind-libdw.c b/tools/perf/util/unwind-libdw.c
> index 4ccfcc7c2dfca..d49901b1571e9 100644
> --- a/tools/perf/util/unwind-libdw.c
> +++ b/tools/perf/util/unwind-libdw.c
[ ... ]
> +/*
> + * libdw expects a 32-bit task's words zero-extended. A recording of the
> + * other byte order was swapped in 8-byte units when it was read (see
> + * perf_event__all64_swap()), so a 4-byte word is picked out of its unit with
> + * that swap undone, as for PERF_SAMPLE_CPU in __evsel__parse_sample().
> + */
> +static Dwarf_Word stack_word(struct stack_dump *stack, int offset, size_t len,
> + bool swapped)
> +{
> + union u64_swap u;
> +
> + if (len == sizeof(u64))
> + return *(Dwarf_Word *)&stack->data[offset];
> + if (!swapped)
> + return *(u32 *)&stack->data[offset];
> +
> + u.val64 = bswap_64(*(u64 *)&stack->data[offset & ~7]);
[Severity: Low]
Does this bitwise logic truncate the offset to a 4-byte boundary?
If a DWARF CFI expression requests a stack read at an unaligned address
during cross-endian unwinding, the calculation discards the unaligned bits.
While register unwinding typically targets 4-byte aligned addresses on
32-bit architectures, could a malformed or custom ELF with non-standard
CFI trigger an unaligned read? If so, would this extract the wrong bytes
instead of the requested data, potentially corrupting the unwind results?
> + return bswap_32(u.val32[(offset & 4) / 4]);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260923193432.2489729-1-stian@itx.no?part=1
next prev parent reply other threads:[~2026-09-23 19:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 19:34 [PATCH] perf unwind-libdw: Fix reading the stack of a 32-bit task Stian Halseth
2026-09-23 19:45 ` sashiko-bot [this message]
2026-09-23 20:29 ` Stian Halseth
2026-09-23 20:33 ` Ian Rogers
2026-09-24 17:08 ` Arnaldo Carvalho de Melo
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=20260923194534.C89B71F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=stian@itx.no \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox