Re: [PATCH 17/28] perf header: Propagate feature section processing errors

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Heap buffer overflow in `do_read_bitmap()` due to 64-bit to 32-bit integer truncation when allocating memory via `bitmap_zalloc()`.
--

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

perf header: Propagate feature section processing errors

This commit ensures that perf_session__read_header() properly checks
feature section processor return values and fails the session on error.
It also changes the stubs for optional libraries like libtraceevent to
return 0 instead of -1, allowing files to be opened when these libraries
are missing, and skips feature processing for truncated files.

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

[ ... ]

> @@ -2748,8 +2748,9 @@ static int process_tracing_data(struct feat_fd *ff __maybe_unused, void *data __
>  
>  	return ret < 0 ? -1 : 0;
>  #else
> -	pr_err("ERROR: Trying to read tracing data without libtraceevent support.\n");
> -	return -1;
> +	/* Not an error — the feature is simply unsupported in this build */
> +	pr_debug("Tracing data present but libtraceevent not available, skipping.\n");
> +	return 0;
>  #endif
>  }

Does changing this return value from -1 to 0 expose a pre-existing
issue in do_read_bitmap() when parsing perf.data files on builds lacking
libtraceevent support?

Previously, returning -1 completely aborted feature parsing. By returning 0
here, the parser sequentially reaches HEADER_MEM_TOPOLOGY and exposes
do_read_bitmap() to untrusted input.

In do_read_bitmap(), a 64-bit size is read directly from the file and passed
to bitmap_zalloc(), which expects a 32-bit integer. A maliciously crafted
size like 0x100000004 will truncate to 4, allocating an 8-byte buffer. The
loop then uses the original 64-bit size to write values, which can cause a
heap buffer overflow.

I see this is fixed later in the series by the commit "perf header:
Validate bitmap size before allocating in do_read_bitmap()".

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