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

[Masami Hiramatsu (Google) <mhiramat@kernel.org>]

On Tue, 06 Oct 2026 23:06:23 +0000, sashiko-bot@kernel.org <sashiko-bot@kernel.org> wrote:

> [Severity: High]
> This successfully prevents KASLR bypass via the .function suffix, but does
> it leave a similar memory disclosure oracle open for standard string matches
> on pointer fields?
>
> Later in parse_pred(), if the field is a pointer and the user omits the
> .ustring suffix, the predicate is assigned FILTER_PRED_FN_PCHAR without
> checking perf_allow_tracepoint():
>
> kernel/trace/trace_events_filter.c:parse_pred() {
>     ...
> 		if (ustring)
> 			pred->fn_num = FILTER_PRED_FN_PCHAR_USER;
> 		else
> 			pred->fn_num = FILTER_PRED_FN_PCHAR;
>     ...
> }
>
> Could an unprivileged user create a counting perf event without
> PERF_SAMPLE_RAW on a syscall tracepoint like sys_enter_openat (which is
> allowed because syscall tracepoints have the TRACE_EVENT_FL_CAP_ANY flag)?
>
> If they set a string wildcard filter (e.g., ~ "secret*") on a pointer field
> like filename, wouldn't the filter engine read from the user-controlled
> kernel_addr when evaluating FILTER_PRED_FN_PCHAR?
>
> kernel/trace/trace_events_filter.c:test_string() {
>     ...
> 	/* For safety, do not trust the string pointer */
> 	if (strncpy_from_kernel_nofault(kstr, str, USTRING_BUF_SIZE) < 0)
> 		return NULL;
>     ...
> }
>
> If the kernel memory successfully matches the wildcard, the perf counter
> increments, which could allow an attacker to extract arbitrary kernel memory
> byte-by-byte.
>
> Should perf_allow_tracepoint() also be checked before assigning
> FILTER_PRED_FN_PCHAR to prevent this disclosure?

Ah, indeed. Kyle, can you update the patch according to this comment?

Thank you,


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>