Re: [PATCH 23/28] perf tools: Harden compressed event processing

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Incomplete protection against `size_t` overflow in `decomp_len` calculation allows a massive out-of-bounds write on 32-bit architectures.
--

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

perf tools: Harden compressed event processing

This commit adds several checks to the compressed event decompression pipeline.
It guards against decomp_last_rem underflows, validates comp_mmap_len size
and alignment, and ensures compressed event headers are properly sized.

> diff --git a/tools/perf/util/tool.c b/tools/perf/util/tool.c
> index 013c7839e2cfd..0a5d17946032d 100644
> --- a/tools/perf/util/tool.c
> +++ b/tools/perf/util/tool.c
[ ... ]
> @@ -24,7 +24,15 @@ static int perf_session__process_compressed_event(const struct perf_tool *tool _
>  	size_t mmap_len, decomp_len = perf_session__env(session)->comp_mmap_len;
>  	struct decomp *decomp, *decomp_last = session->active_decomp->decomp_last;
>  
> +	if (!decomp_len) {
> +		pr_err("Compressed events found but HEADER_COMPRESSED not set\n");
> +		return -1;
> +	}
> +
>  	if (decomp_last) {
> +		/* Prevent u64 underflow in decomp_last_rem */
> +		if (decomp_last->head > decomp_last->size)
> +			return -1;
>  		decomp_last_rem = decomp_last->size - decomp_last->head;
>  		decomp_len += decomp_last_rem;

When decomp_len is calculated as comp_mmap_len + decomp_last_rem, could it
overflow a 32-bit size_t and wrap around to an undersized value?

While the patch caps comp_mmap_len at ~2 GB to prevent immediate overflow,
it seems a crafted perf.data file with nested or incomplete compressed
events could prevent decomp_last->head from advancing. This would cause
decomp_last_rem to accumulate and grow up to ~4 GB.

The mmap allocation would succeed with this smaller size, but the subsequent
memcpy could use decomp_last_rem (which fits in 32 bits as ~4 GB) as the
copy length, copying ~4 GB of data into a ~2 GB allocation and causing an
out-of-bounds write.

This issue appears to be fixed later in the series by commit 7a68686c9f43c
("perf session: Check for decompression buffer size overflow").

>  	}

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