All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Arnaldo Carvalho de Melo" <acme@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 05/12] perf jitdump: Bounds-check debug entry byte-swap loop
Date: Mon, 31 Aug 2026 13:23:56 +0000	[thread overview]
Message-ID: <20260831132356.C07401F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260831131110.4681-6-acme@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unaligned memory accesses leading to SIGBUS crashes on strict-alignment architectures.
--

commit 947f2eb889b5646cf554f70f7bd7ac567ceaa090
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf jitdump: Bounds-check debug entry byte-swap loop
    
This commit replaces fixed-size array indexing with pointer arithmetic using
debug_entry_next to iterate variable-length debug entries in
JIT_CODE_DEBUG_INFO records. It also adds bounds checking against the total
record size to prevent out-of-bounds reads.

> diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c
> index f79e9420c6bd7..7efbaa07f1ba7 100644
> --- a/tools/perf/util/jitdump.c
> +++ b/tools/perf/util/jitdump.c

[ ... ]

> @@ -320,14 +320,32 @@ jit_get_next_entry(struct jit_buf_desc *jd)
>  	switch(id) {
>  	case JIT_CODE_DEBUG_INFO:
>  		if (jd->needs_bswap) {
> +			void *end = (void *)jr + jr->prefix.total_size;
> +			struct debug_entry *ent;
>  			uint64_t n;
> +
>  			jr->info.code_addr = bswap_64(jr->info.code_addr);
>  			jr->info.nr_entry  = bswap_64(jr->info.nr_entry);
> -			for (n = 0 ; n < jr->info.nr_entry; n++) {
> -				jr->info.entries[n].addr    = bswap_64(jr->info.entries[n].addr);
> -				jr->info.entries[n].lineno  = bswap_32(jr->info.entries[n].lineno);
> -				jr->info.entries[n].discrim = bswap_32(jr->info.entries[n].discrim);
> +
> +			/*
> +			 * debug_entry has a variable-length name[], so array
> +			 * indexing would compute wrong offsets — use
> +			 * debug_entry_next() and bounds-check each entry.
> +			 */
> +			ent = &jr->info.entries[0];
> +			for (n = 0; n < jr->info.nr_entry; n++) {
> +				if ((void *)ent + sizeof(*ent) > end)
> +					break;
> +				/* name must be NUL-terminated within the record */
> +				if (!memchr(ent->name, '\0', (char *)end - ent->name))
> +					break;
> +				ent->addr    = bswap_64(ent->addr);
> +				ent->lineno  = bswap_32(ent->lineno);
> +				ent->discrim = bswap_32(ent->discrim);

[Severity: Medium]
Does this code risk triggering unaligned memory accesses and SIGBUS crashes
on strict-alignment architectures?

In jitdump files, the debug_entry structure is packed with a
variable-length name string without padding. The pointer arithmetic in
debug_entry_next advances the ent pointer by the exact string length
(including the NUL byte).

If the string has an odd length, subsequent ent pointers will no longer
be aligned to an 8-byte boundary. Because the struct lacks the __packed
attribute, the compiler assumes natural alignment.

When it emits standard aligned load and store instructions for the 64-bit
addr and 32-bit lineno fields, they will trap when receiving an unaligned
address while parsing cross-endian jitdump files in jit_get_next_entry.

> +				ent = debug_entry_next(ent);
>  			}
> +			/* clamp so downstream consumers don't overrun */
> +			jr->info.nr_entry = n;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831131110.4681-1-acme@kernel.org?part=5

  reply	other threads:[~2026-08-31 13:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 13:10 [PATCHES v4 0/12] perf jitdump: Input validation hardening Arnaldo Carvalho de Melo
2026-08-31 13:10 ` [PATCH 01/12] perf jitdump: Fix extended header read that always fails Arnaldo Carvalho de Melo
2026-08-31 13:22   ` sashiko-bot
2026-08-31 13:10 ` [PATCH 02/12] perf jitdump: Fix debug_data and unwinding_data leaks Arnaldo Carvalho de Melo
2026-08-31 13:24   ` sashiko-bot
2026-08-31 13:10 ` [PATCH 03/12] perf jitdump: Validate code_size against total_size in code load Arnaldo Carvalho de Melo
2026-08-31 13:21   ` sashiko-bot
2026-08-31 13:11 ` [PATCH 04/12] perf jitdump: Prevent integer underflow in debug info size calculation Arnaldo Carvalho de Melo
2026-08-31 13:22   ` sashiko-bot
2026-08-31 13:11 ` [PATCH 05/12] perf jitdump: Bounds-check debug entry byte-swap loop Arnaldo Carvalho de Melo
2026-08-31 13:23   ` sashiko-bot [this message]
2026-08-31 13:11 ` [PATCH 06/12] perf jitdump: Check snprintf return before computing header size Arnaldo Carvalho de Melo
2026-08-31 13:23   ` sashiko-bot
2026-08-31 13:11 ` [PATCH 07/12] perf jitdump: Fix funlockfile on unlocked stream in jit_open() error path Arnaldo Carvalho de Melo
2026-08-31 13:23   ` sashiko-bot
2026-08-31 13:11 ` [PATCH 08/12] perf jitdump: Free event in jit_repipe_code_move() Arnaldo Carvalho de Melo
2026-08-31 13:21   ` sashiko-bot
2026-08-31 13:11 ` [PATCH 09/12] perf jitdump: Use dirname() return value in jit_open() Arnaldo Carvalho de Melo
2026-08-31 13:19   ` sashiko-bot
2026-08-31 13:11 ` [PATCH 10/12] perf jitdump: Validate debug entries on native (non-swap) path Arnaldo Carvalho de Melo
2026-08-31 13:23   ` sashiko-bot
2026-08-31 13:11 ` [PATCH 11/12] perf jitdump: Validate sym string NUL-termination in code load Arnaldo Carvalho de Melo
2026-08-31 13:31   ` sashiko-bot
2026-08-31 13:11 ` [PATCH 12/12] perf jitdump: Validate unwinding sizes against record payload Arnaldo Carvalho de Melo
2026-08-31 13:35   ` sashiko-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-08-06 12:35 [PATCHES v3 0/12] perf jitdump: Input validation hardening Arnaldo Carvalho de Melo
2026-08-06 12:35 ` [PATCH 05/12] perf jitdump: Bounds-check debug entry byte-swap loop Arnaldo Carvalho de Melo
2026-08-06 12:51   ` sashiko-bot
2026-08-06 15:21     ` 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=20260831132356.C07401F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=acme@kernel.org \
    --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.