Linux Perf Users
 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 12/15] perf bpf: Bounds-check array offsets in bpil_offs_to_addr()
Date: Fri, 12 Jun 2026 00:51:33 +0000	[thread overview]
Message-ID: <20260612005133.85D6C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612003444.50723-13-acme@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Information leak of heap address due to incomplete offset sanitization.
--

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

perf bpf: Bounds-check array offsets in bpil_offs_to_addr()

This commit adds a bounds check to bpil_offs_to_addr() for offsets coming from
untrusted perf.data files. When an offset exceeds data_len, the offset fields
are zeroed out and the pointer conversion is skipped to prevent out-of-bounds
pointer construction.

> diff --git a/tools/perf/util/bpf-utils.c b/tools/perf/util/bpf-utils.c
> --- a/tools/perf/util/bpf-utils.c
> +++ b/tools/perf/util/bpf-utils.c

[ ... ]

> @@ -264,12 +264,26 @@ void bpil_offs_to_addr(struct perf_bpil *info_linear)
>  	for (i = PERF_BPIL_FIRST_ARRAY; i < PERF_BPIL_LAST_ARRAY; ++i) {
>  		const struct bpil_array_desc *desc = &bpil_array_desc[i];
>  		__u64 addr, offs;
> +		__u32 count, size;
>  
>  		if ((info_linear->arrays & (1UL << i)) == 0)
>  			continue;
>  
>  		offs = bpf_prog_info_read_offset_u64(&info_linear->info,
>  						     desc->array_offset);
> +		count = bpf_prog_info_read_offset_u32(&info_linear->info,
> +						      desc->count_offset);
> +		size = bpf_prog_info_read_offset_u32(&info_linear->info,
> +						     desc->size_offset);
> +		/* offset and extent from perf.data are untrusted — keep within data[] */
> +		if (offs >= info_linear->data_len ||
> +		    (u64)count * size > info_linear->data_len - offs) {
> +			bpf_prog_info_set_offset_u64(&info_linear->info,
> +						     desc->array_offset, 0);
> +			bpf_prog_info_set_offset_u32(&info_linear->info,
> +						     desc->count_offset, 0);
> +			continue;

[Severity: Medium]
Does skipping this conversion without clearing the corresponding array bit
in info_linear->arrays leak the heap address later?

When the bounds check fails, the offset is set to 0, but the active array
bit remains set in the info_linear->arrays bitmask.

Later, if the tool rewrites the data (such as during perf inject or archive),
write_bpf_prog_info() will call bpil_addr_to_offs(), which processes all
arrays that still have their bits set. It subtracts the heap base pointer
(info_linear->data) from the array address.

Since the address was explicitly forced to 0 here, the calculation becomes
0 - ptr_to_u64(info_linear->data). This results in the two's complement of
the heap address, which is then saved into the bpf_prog_info struct and
written back out to the perf.data file.

Would it be safer to also clear the active array bit via
info_linear->arrays &= ~(1UL << i) when zeroing out these offsets?

> +		}
>  		addr = offs + ptr_to_u64(info_linear->data);
>  		bpf_prog_info_set_offset_u64(&info_linear->info,
>  					     desc->array_offset, addr);
>  	}
>  }

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

  reply	other threads:[~2026-06-12  0:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12  0:34 [PATCHES v1 00/15] perf tools: Fix pre-existing bugs in symbols, dso, bpf, sched, c2c, hwmon, and cs-etm Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 01/15] perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 02/15] perf symbols: Validate p_filesz before use in filename__read_build_id() Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 03/15] perf symbols: Use fixed buffer in sysfs__read_build_id() for no-libelf build Arnaldo Carvalho de Melo
2026-06-12  0:47   ` sashiko-bot
2026-06-12  0:34 ` [PATCH 04/15] perf symbols: Break infinite loop on zero-filled notes in sysfs__read_build_id() Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 05/15] perf dso: Fix heap overflow in dso__get_filename() on decompressed path Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 06/15] perf dso: Set error code when open() fails on uncompressed fallback path Arnaldo Carvalho de Melo
2026-06-12  0:54   ` sashiko-bot
2026-06-12  0:34 ` [PATCH 07/15] perf tools: Use snprintf() for root_dir path construction Arnaldo Carvalho de Melo
2026-06-12  2:54   ` sashiko-bot
2026-06-12  0:34 ` [PATCH 08/15] perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items() Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 09/15] perf sched: Replace (void*)1 sentinel with proper runtime allocation Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 10/15] perf bpf: Validate func_info_rec_size and sub_id in synthesize_bpf_prog_name() Arnaldo Carvalho de Melo
2026-06-12  0:52   ` sashiko-bot
2026-06-12  0:34 ` [PATCH 11/15] perf bpf: Reject oversized BPF metadata events that truncate header.size Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 12/15] perf bpf: Bounds-check array offsets in bpil_offs_to_addr() Arnaldo Carvalho de Melo
2026-06-12  0:51   ` sashiko-bot [this message]
2026-06-12  0:34 ` [PATCH 13/15] perf c2c: Free format list entries when releasing c2c hist entries Arnaldo Carvalho de Melo
2026-06-12  0:58   ` sashiko-bot
2026-06-12  0:34 ` [PATCH 14/15] perf symbols: Add O_NONBLOCK to DSO open() calls for untrusted paths Arnaldo Carvalho de Melo
2026-06-12  0:34 ` [PATCH 15/15] perf cs-etm: Reject CPU IDs that would overflow signed comparison Arnaldo Carvalho de Melo
2026-06-12  1:00   ` sashiko-bot

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=20260612005133.85D6C1F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox