Re: [PATCH] perf cs-etm: Avoid truncating AUX buffer sizes to int

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Medium] Integer truncation leading to infinite loop (DoS) in cs-etm decoder for AUX trace blocks >= 4GB.
--

--- Patch [1]: [PATCH] perf cs-etm: Avoid truncating AUX buffer sizes to int ---
commit 1f84d1046e544ee9b629c80e55d031135982e6db
Author: Leo Yan <leo.yan@arm.com>

perf cs-etm: Avoid truncating AUX buffer sizes to int

This commit prevents truncation of large AUX buffer sizes when returning
them from cs_etm__get_trace(). Instead of returning the buffer length as
an int, which can overflow for sizes over 2GB, the function now returns 0
on success and uses etmq->buf_len to track the size. The caller
cs_etm__get_data_block() is updated to return 1 when data is available.

> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 95e3ec1171acc..114b3cd2da495 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -1467,8 +1467,7 @@ cs_etm__get_trace(struct cs_etm_queue *etmq)
>  	etmq->buf_used = 0;
>  	etmq->buf_len = aux_buffer->size;
>  	etmq->buf = aux_buffer->data;
> -
> -	return etmq->buf_len;
> +	return 0;
>  }

[Severity: Medium]
This is a pre-existing issue, but since we are fixing buffer size
truncations for large AUX trace blocks, should we also address the
truncation in cs_etm_decoder__process_data_block()?

When an AUX trace block size is 4GB or larger, etmq->buf_len (a 64-bit
size_t) is eventually passed down to cs_etm_decoder__process_data_block()
as the len parameter. In tools/perf/util/cs-etm-decoder/cs-etm-decoder.c:

		} else if (OCSD_DATA_RESP_IS_CONT(prev_return)) {
			cur = ocsd_dt_process_data(decoder->dcd_tree,
						   OCSD_OP_DATA,
						   indx + processed,
						   len - processed,
						   &buf[processed],
						   &count);
			processed += count;

The OpenCSD library function ocsd_dt_process_data() uses a 32-bit integer
for the buffer size. The expression len - processed is implicitly
truncated to a 32-bit integer.

If len - processed is exactly a multiple of 4GB (or reaches a multiple
of 4GB during processing), the truncated size becomes 0. This instructs
ocsd_dt_process_data() to process 0 bytes, returning count = 0.

Since processed does not increase, could this result in an infinite loop
when processing large or maliciously crafted perf.data files?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-perf_cs_etm_fix_big_size-v1-1-97ded24636b1@arm.com?part=1