Re: [PATCH] tracing/filters: Check perf permissions before resolving .function

[Kyle Zeng]

On Wed, Oct 07, 2026 at 03:44:20AM +0000, Masami Hiramatsu wrote:
> On Tue, 06 Oct 2026 15:51:12 -0700, Kyle Zeng <kylebot@xxxxxxxxxx> wrote:
> > perf_trace_event_perm() allows tracepoint counters that do not request
> > PERF_SAMPLE_RAW without raw tracepoint permissions. A self-targeted,
> > disabled event with exclude_kernel=1 can therefore reach the filter
> > compiler even at perf_event_paranoid=2.
> >
> > The .function suffix accepts any field of sizeof(long) and resolves its
> > operand through kallsyms_lookup_name() and kallsyms_lookup_size_offset().
> > The success or failure of a numeric filter discloses whether an address
> > belongs to a known kernel symbol range. On x86-64 this can be used to
> > recover the randomized kernel image base. A named filter also exposes
> > the resolved symbol range through the counter when the tracepoint field
> > is controlled by the caller, as with a syscall argument.
> >
> > Pass the filter's perf origin to the predicate parser and require
> > perf_allow_tracepoint() before resolving a .function operand. This uses
> > the same sysctl, initial-namespace capability and LSM policy as raw
> > tracepoint access, and closes both the numeric and named-symbol oracles.
> > Do not change ordinary perf counting filters or filters created through
> > the separately controlled tracefs interfaces.
> 
> Good catch!
> 
> >
> > Fixes: e6745a4da964 ("tracing: Add a way to filter function addresses to function names")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Assisted-by: Codex:gpt-6-astra
> 
> nit: This should be 
> 
> Assisted-by: LLM

Didn't know there was a change of convention. Should I send in a v2 or
it will be picked up automatically?

Thanks,
Kyle

> 
> > Signed-off-by: Kyle Zeng <kylebot@xxxxxxxxxx>
> 
> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
> 
> Thanks!
> 
> 
> -- 
> Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>