On Tue, 06 Oct 2026 23:06:23 +0000, [email protected]
<[email protected]> 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) <[email protected]>
