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

On Tue, 06 Oct 2026 23:06:23 +0000, sashiko-bot@kernel.org [off-list ref] 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) [off-list ref]