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 2 potential issue(s) to consider:

New issues:
- [Medium] Unconditional bitmask validation in `__bpf_event__print_bpf_prog_info` silently drops BPF program info for programs without subprograms (e.g., non-JITed or non-BTF programs).

Pre-existing issues:
- [High] Incomplete validation of BPF prog info array bitmasks allows arbitrary pointer dereferences via crafted `perf.data` files.
--

commit c8a78c4f19f095efa7672153271eb294c216288b
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.

> 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 does this incomplete bitmask
validation allow arbitrary pointer dereferences via crafted perf.data files?

The required_arrays bitmask enforces PERF_BPIL_JITED_KSYMS and
PERF_BPIL_JITED_FUNC_LENS but omits PERF_BPIL_PROG_TAGS and
PERF_BPIL_FUNC_INFO.

Later in this function, synthesize_bpf_prog_name() is called, which blindly
casts and dereferences info->prog_tags and info->func_info without checking
if their array presence bits were set.

Additionally, symbol__disassemble_bpf_libbfd() in tools/perf/util/libbfd.c
lacks any array bitmask validation and blindly casts and dereferences
jited_prog_insns and jited_ksyms. A crafted perf.data file can provide
these fields as raw file offsets while unsetting their corresponding bits,
bypassing the bpil_offs_to_addr() conversion and leading to segmentation
faults.

> +	__u32 *prog_lens;
> +	__u64 *prog_addrs;
>  	char name[KSYM_NAME_LEN];
>  	struct btf *btf = NULL;
>  	u32 sub_prog_cnt, i;
> @@ -974,6 +981,13 @@ void __bpf_event__print_bpf_prog_info(struct bpf_prog_info *info,
>  	    sub_prog_cnt != info->nr_jited_func_lens)
>  		return;
>  
> +	/* Ensure the arrays were present and converted by bpil_offs_to_addr() */
> +	if ((info_linear->arrays & required_arrays) != required_arrays)
> +		return;

[Severity: Medium]
Will this unconditional check silently drop BPF program info for programs
without subprograms?

The function bpil_offs_to_addr() has an edge case where it clears an array's
presence bit if its count is 0 and it is placed at the end of the data buffer
(offset equals data_len).

Valid BPF programs that legitimately have nr_jited_ksyms == 0 and
nr_jited_func_lens == 0 (such as non-JITed programs) will have these bits
unset. The new validation check will unconditionally fail here, causing
perf report --header to silently omit their basic program info.

Should this check only be enforced when sub_prog_cnt > 0?

> +
> +	prog_lens = (__u32 *)(uintptr_t)(info->jited_func_lens);
> +	prog_addrs = (__u64 *)(uintptr_t)(info->jited_ksyms);
> +
>  	if (info->btf_id) {

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