Re: [PATCH v14 2/5] perf inject/aslr: Add ASLR tool infrastructure and MMAP tracking

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The ASLR tool fails to remap the `pgoff` field for user-space anonymous `MMAP` and `MMAP2` events, leaking original randomized virtual addresses.
- [High] The tool leaks kernel ASLR addresses through unhandled `kprobe_addr` and `kprobe_func` fields in `perf_event_attr`.
--

commit 5f7118d61e85f58390f8e97238a20e6193ea5f8d
Author: Ian Rogers <irogers@google.com>

perf inject/aslr: Add ASLR tool infrastructure and MMAP tracking

If perf.data files are taken from one machine to another they may
leak virtual addresses and so weaken ASLR on the machine they are
coming from. Add an aslr option for perf inject that remaps all
virtual addresses, or drops data/events, so that the virtual address
information isn't leaked.

This patch introduces the core ASLR remapping tool infrastructure and
implements remapping/tracking for metadata events (MMAP, MMAP2, COMM,
FORK, EXIT, KSYMBOL, TEXT_POKE). Sample events are delegated without
remapping for now.

> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 75ffe31d03fea..65c7eccccf4d2 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
[ ... ]
> @@ -2923,12 +2963,25 @@ int cmd_inject(int argc, const char **argv)
>  
>  	ret = __cmd_inject(&inject);
>  
> +	if (inject.aslr) {
> +		struct evsel *evsel;
> +
> +		evlist__for_each_entry(inject.session->evlist, evsel) {
> +			evsel->core.attr.sample_type &= ASLR_SUPPORTED_SAMPLE_TYPE;
> +
> +			if (evsel->core.attr.type == PERF_TYPE_BREAKPOINT)
> +				evsel->core.attr.bp_addr = 0;

[Severity: High]
Does this code leak kernel ASLR addresses through unhandled kprobe_addr and
kprobe_func fields?

For dynamic PMUs like perf_kprobe and perf_uprobe, attr.type is assigned a
dynamic identifier rather than a fixed constant like PERF_TYPE_BREAKPOINT.
The perf_event_attr struct utilizes the same config1 and config2 union fields
to store kprobe_func/uprobe_path and kprobe_addr/probe_offset.

If this only checks for PERF_TYPE_BREAKPOINT, it fails to scrub these union
fields for kprobe events, which could leak exact kernel ASLR addresses and
perf record process pointers into the output perf.data file's attribute
headers.

> +		}
> +	}
> +
>  	guest_session__exit(&inject.guest_session);

> diff --git a/tools/perf/util/aslr.c b/tools/perf/util/aslr.c
> new file mode 100644
> index 0000000000000..4b4b00b4d52d9
> --- /dev/null
> +++ b/tools/perf/util/aslr.c
[ ... ]
> +static int aslr_tool__process_mmap(const struct perf_tool *tool,
> +				   union perf_event *event,
> +				   struct perf_sample *sample,
> +				   struct machine *machine)
> +{
[ ... ]
> +	/* Remaps the mmap.start. */
> +	new_event->mmap.start = aslr_tool__findnew_mapping(aslr, thread, cpumode,
> +							   event->mmap.start,
> +							   event->mmap.len,
> +							   event->mmap.pgoff);
> +	if (cpumode == PERF_RECORD_MISC_KERNEL || cpumode == PERF_RECORD_MISC_GUEST_KERNEL)
> +		new_event->mmap.pgoff = new_event->mmap.start;

[Severity: High]
Does this fail to remap the pgoff field for user-space anonymous MMAP events,
potentially leaking original randomized virtual addresses?

The Linux kernel's perf_event_mmap_event() function unconditionally sets
pgoff = (u64)vma->vm_pgoff << PAGE_SHIFT for all mappings. For anonymous
mappings ([anon], [stack], [heap]), vma->vm_pgoff is initialized as
addr >> PAGE_SHIFT, meaning pgoff literally contains the original randomized
virtual address.

If pgoff is copied verbatim from the original event for user-space mappings, it
could directly leak the original ASLR addresses into the output perf.data file.

> +	err = delegate->mmap(delegate, new_event, sample, machine);
> +	thread__put(thread);
> +	return err;
> +}
> +
> +static int aslr_tool__process_mmap2(const struct perf_tool *tool,
> +				    union perf_event *event,
> +				    struct perf_sample *sample,
> +				    struct machine *machine)
> +{
[ ... ]
> +	/* Remaps the mmap.start. */
> +	new_event->mmap2.start = aslr_tool__findnew_mapping(aslr, thread, cpumode,
> +							    event->mmap2.start,
> +							    event->mmap2.len,
> +							    event->mmap2.pgoff);
> +	if (cpumode == PERF_RECORD_MISC_KERNEL || cpumode == PERF_RECORD_MISC_GUEST_KERNEL)
> +		new_event->mmap2.pgoff = new_event->mmap2.start;

[Severity: High]
Can this similarly leak original randomized virtual addresses for MMAP2 events?

Like with aslr_tool__process_mmap() above, skipping the pgoff remapping for
user-space anonymous mappings here leaves the original ASLR addresses
unmodified.

> +	err = delegate->mmap2(delegate, new_event, sample, machine);
> +	thread__put(thread);
> +	return err;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605205649.2566948-1-irogers@google.com?part=2