Re: [PATCH v11 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 1 potential issue(s) to consider:
- [High] `remap_addresses__hash` hashes the RC pointer handle for `dso` directly, breaking hashmap lookups when `REFCNT_CHECKING` is enabled.
--

commit 4e905ffc55cc982a92f6bbc5744803fa9093aab4
Author: Ian Rogers <irogers@google.com>

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

This patch adds an --aslr option to perf inject that remaps virtual
addresses to prevent ASLR leaks when transferring perf.data files. It
introduces the core remapping infrastructure and implements tracking for
metadata events.

> diff --git a/tools/perf/util/aslr.c b/tools/perf/util/aslr.c
> new file mode 100644
> index 0000000000000..375a0355f2812
> --- /dev/null
> +++ b/tools/perf/util/aslr.c
[ ... ]
> +static size_t remap_addresses__hash(long _key, void *ctx __maybe_unused)
> +{
> +	struct remap_addresses_key *key = (struct remap_addresses_key *)_key;
> +
> +	return (size_t)key->machine ^ (size_t)key->dso ^ key->invariant ^ key->pid;

[Severity: High]
Will this hash function work correctly when REFCNT_CHECKING is enabled?

The struct dso is reference-counted. Under REFCNT_CHECKING (such as when
built with ASAN/LSAN), dso__get() allocates and returns a completely new
pointer handle.

Because the pointer handle itself is hashed here rather than the underlying
object, two handles pointing to the same dso will hash to different buckets.

Since aslr_tool__findnew_mapping() acquires a new reference via dso__get()
before insertion, hashmap__find() will systematically fail to locate
previously inserted keys. This breaks the ASLR remapping lookup and causes
memory leaks.

Should this resolve the underlying pointer before hashing, for example by
using RC_CHK_ACCESS(key->dso) or similar?

> +}
[ ... ]

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