Re: [PATCH 8/9] perf bpf: Validate array presence before casting BPF prog info pointers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete validation of BPF program info arrays leaves paths to arbitrary pointer dereferences open in synthesize_bpf_prog_name().
- [High] Missing array bitmask validation in symbol__disassemble_bpf_libbfd() leads to arbitrary pointer dereferences.
- [High] Attacker-controlled length in dso__read_symbol() triggers assertion failure (DoS) or out-of-bounds heap read.
--

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

perf bpf: Validate array presence before casting BPF prog info pointers

Several functions cast bpf_prog_info fields (jited_ksyms,
jited_func_lens, jited_prog_insns) from u64 to pointers and
dereference them. These fields are only valid pointers if
bpil_offs_to_addr() converted their file offsets to addresses, which
only happens when the corresponding PERF_BPIL_* bits are set in
info_linear->arrays.

> diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
> index 57d53ba848359..fa3ebc8ea7f09 100644
> --- a/tools/perf/util/bpf-event.c
> +++ b/tools/perf/util/bpf-event.c
[ ... ]
> @@ -959,12 +963,15 @@ int evlist__add_bpf_sb_event(struct evlist *evlist, struct perf_env *env)
>  	return evlist__add_sb_event(evlist, &attr, bpf_event__sb_cb, env);
>  }
>  
> -void __bpf_event__print_bpf_prog_info(struct bpf_prog_info *info,
> +void __bpf_event__print_bpf_prog_info(struct perf_bpil *info_linear,
>  				      struct perf_env *env,
>  				      FILE *fp)
>  {
> -	__u32 *prog_lens = (__u32 *)(uintptr_t)(info->jited_func_lens);
> -	__u64 *prog_addrs = (__u64 *)(uintptr_t)(info->jited_ksyms);
> +	struct bpf_prog_info *info = &info_linear->info;
> +	__u64 required_arrays = (1UL << PERF_BPIL_JITED_KSYMS) |
> +				(1UL << PERF_BPIL_JITED_FUNC_LENS);

[Severity: High]
This isn't a bug introduced by this patch, but it looks like the validation
remains incomplete. Could this leave a path for arbitrary pointer
dereferences open in synthesize_bpf_prog_name()?

If a crafted perf.data file omits PERF_BPIL_PROG_TAGS and PERF_BPIL_FUNC_INFO
from the bitmask but provides raw file offsets, bpil_offs_to_addr() won't
convert or clear them. Since required_arrays doesn't check these flags,
synthesize_bpf_prog_name() will then unconditionally cast info->prog_tags and
conditionally cast info->func_info to pointers and dereference them.

Should PERF_BPIL_PROG_TAGS and PERF_BPIL_FUNC_INFO be added to the
required_arrays bitmask check here?

[ ... ]
> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index 1a2fc6d18da74..79f1a30f3683d 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
[ ... ]
> @@ -1995,6 +2001,10 @@ const u8 *dso__read_symbol(struct dso *dso, const char *symfs_filename,
>  			return NULL;
>  		}
>  		info_linear = info_node->info_linear;
> +		if (!(info_linear->arrays & (1UL << PERF_BPIL_JITED_INSNS))) {
> +			errno = SYMBOL_ANNOTATE_ERRNO__BPF_MISSING_BTF;
> +			return NULL;
> +		}
>  		assert(len <= info_linear->info.jited_prog_len);

[Severity: High]
This is a pre-existing issue, but does this assertion evaluate attacker
controlled lengths?

In dso__read_symbol(), the local variable len is calculated using sym->start
and sym->end from a parsed PERF_RECORD_KSYMBOL event, which comes from the
perf.data file.

Since both len and jited_prog_len come from the data source, could this
assertion be forced to fail, crashing the tool? Or, if perf is compiled
with NDEBUG, couldn't this bypass the check entirely, allowing an
out-of-bounds heap read that exposes memory contents in the disassembly output?

[Severity: High]
This is a pre-existing issue, but it appears a similar lack of array bitmask
validation exists in symbol__disassemble_bpf_libbfd() in
tools/perf/util/libbfd.c. Was this file missed during the conversion?

Looking at symbol__disassemble_bpf_libbfd(), it directly casts and
dereferences info_linear->info.jited_prog_insns and
info_linear->info.jited_ksyms without checking if PERF_BPIL_JITED_INSNS or
PERF_BPIL_JITED_KSYMS are set in the info_linear->arrays bitmask.

Additionally, it calls bpf_prog_linfo__new(), which blindly copies memory
from info->line_info using memcpy(). A crafted perf.data file could provide
raw file offsets for these fields while unsetting the bitmask flags,
bypassing address conversion and potentially causing arbitrary memory reads.

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