Re: [PATCH 07/12] perf jitdump: Free event in jit_repipe_code_move()

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

Pre-existing issues:
- [High] Potential heap out-of-bounds read and information leak due to hardcoded memory allocation padding versus dynamic header size.
--

--- Patch [7]: [PATCH 07/12] perf jitdump: Free event in jit_repipe_code_move() ---
commit 11d0d0b8d917333552119016252e41efe5f10dbc
Author: Arnaldo Carvalho de Melo <[email protected]>

perf jitdump: Free event in jit_repipe_code_move()

jit_repipe_code_move() allocates a perf_event with calloc but never
frees it — the 'out' label exits with only perf_sample__exit().

Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
Reported-by: sashiko-bot <[email protected]>
Cc: Stephane Eranian <[email protected]>
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>

> diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c
> index c3f11d1c1d76d..4f52b143cd0da 100644
> --- a/tools/perf/util/jitdump.c
> +++ b/tools/perf/util/jitdump.c
> @@ -683,6 +683,7 @@ static int jit_repipe_code_move(struct jit_buf_desc *jd, union jr_entry *jr)

[Severity: High]
This isn't a bug introduced by this patch, but could the hardcoded + 16
allocation padding lead to an out-of-bounds heap read in
jit_repipe_code_move()?

The event buffer is allocated with a hardcoded 16 bytes of padding:

	event = calloc(1, sizeof(*event) + 16);

Later, the header size is computed dynamically using idr_size:

	event->mmap2.header.size = (sizeof(event->mmap2) -
			(sizeof(event->mmap2.filename) - size) + idr_size);

If the jitted filename path length reaches PATH_MAX, the subtraction
(sizeof(...) - size) approaches 0, making the header.size evaluate to
sizeof(event->mmap2) + idr_size.

When idr_size (the sample ID header payload size) exceeds 16 bytes, which
can happen when multiple PERF_SAMPLE_* flags are requested, the computed
header.size will exceed the allocated chunk size.

Could this cause jit_inject_event() to call perf_data__write() with a size
larger than the allocation, potentially leaking uninitialized heap memory
into the perf.data output file?

>  		build_id__mark_dso_hit(tool, event, &sample, jd->machine);
>  out:
>  	perf_sample__exit(&sample);
> +	free(event);
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7