Re: [PATCH 08/29] perf session: Add validated swap infrastructure with null-termination checks

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Medium] The swap handler for PERF_RECORD_STAT_CONFIG calculates the byte size incorrectly, leaving the last 64-bit value unswapped.
- [Medium] Remaining `deferred_samples` are leaked if sample parsing or delivery fails during `session__flush_deferred_samples`.
- [Medium] Integer overflow in `perf_session__peek_events` allows an infinite loop via crafted `auxtrace.size`.
--

(Note: The format of this review has been altered to provide a free-form
summary of the findings without directly quoting the patch, in order to
comply with recitation restrictions.)

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

perf session: Add validated swap infrastructure with null-termination checks

This commit changes swap callbacks to return an int instead of void to
allow error propagation, adding null-termination checks for several string
event fields.

[Severity: Medium]
This is a pre-existing issue, but I noticed something unusual in the size
calculation for perf_event__stat_config_swap(). When calculating the size
passed to mem_bswap_64(), the code does size += 1 to account for the nr
item itself. However, since mem_bswap_64() expects a byte count and swaps
8-byte chunks, adding just 1 byte results in (16 * nr + 1) total bytes.

Does this cause the function to swap only 2 * nr elements, skipping the
final 64-bit value of the payload on cross-endian machines?

[Severity: Medium]
This is a pre-existing issue, but looking at
session__flush_deferred_samples(), if evlist__parse_sample() or
evlist__deliver_sample() fails, the loop terminates immediately via a
break statement.

Are the remaining items in the evlist->deferred_samples list leaked in
this scenario, since they are not unlinked or freed during an early error
return?

[Severity: Medium]
This is a pre-existing issue, but I have a question about how the offset
is advanced in perf_session__peek_events() for AUXTRACE events. The offset
is incremented by event->auxtrace.size, which is read directly from the
file.

If an excessively large value is provided, could this cause an integer
overflow that wraps around? If offset wraps, could this bypass the
offset < max_offset loop condition and result in an infinite loop when
parsing a malformed perf.data file?

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