Re: [PATCH v10 3/6] perf header: Support memory ranges

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf: memory leak of env->memory_ranges when parsing malformed data
--

commit 1ab84913c01dd8ba27d90b19de21357887b69fea
Author: Thomas Falcon <thomas.falcon@intel.com>

perf header: Support memory ranges

This commit introduces support for tracking different types of memory
ranges, such as persistent or CXL-attached memory. It parses ACPI MRRM
data exposed via sysfs and saves it in the perf.data file header under
a new feature bit.

Link: https://lore.kernel.org/lkml/20250505173819.419271-1-tony.luck@intel.com/

> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index ec2935c0ed04e..38f2da9de5f0d 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c

[ ... ]

> @@ -4227,6 +4372,65 @@ static int process_cpu_domain_info(struct feat_fd *ff, void *data __maybe_unused
>  	return ret;
>  }
>  
> +static int process_memory_ranges(struct feat_fd *ff, void *data __maybe_unused)
> +{
> +	struct perf_env *env = &ff->ph->env;
> +	struct memory_range *ranges, *r;
> +	u32 nr_memory_ranges, i;

[ ... ]

> +	ranges = calloc(nr_memory_ranges, sizeof(*ranges));
> +	if (!ranges)
> +		return -1;
> +
> +	for (i = 0; i < nr_memory_ranges; i++) {
> +		r = &ranges[i];
> +
> +		if (do_read_u64(ff, &r->base))
> +			goto error;
> +		if (do_read_u64(ff, &r->length))
> +			goto error;
> +		if (do_read_u32(ff, (u32 *) &r->node))
> +			goto error;
> +		if (__do_read(ff, &r->local_region_id, sizeof(u8)))
> +			goto error;
> +		if (__do_read(ff, &r->remote_region_id, sizeof(u8)))
> +			goto error;
> +	}
> +
> +	env->memory_ranges = ranges;
> +	env->nr_memory_ranges = nr_memory_ranges;

[Severity: Medium]
If a malformed perf.data file or pipe stream contains multiple
HEADER_MEMORY_RANGES sections, process_memory_ranges() in
tools/perf/util/header.c could be executed multiple times.

Can this assignment cause a memory leak by overwriting env->memory_ranges
without freeing the previously allocated array?

Could this leak be exploited to cause a Denial of Service (OOM) in the
userspace perf tool when processing untrusted pipe streams?

> +
> +	return 0;
> +error:
> +	zfree(&ranges);
> +	return -1;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916163127.318885-1-thomas.falcon@intel.com?part=3