From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: kylebot@openai.com
Cc: linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
rostedt@goodmis.org, mhiramat@kernel.org,
outbounddisclosures@openai.com, Kyle Zeng <kylebot@openai.com>
Subject: Re: [PATCH] tracing: Restrict perf filters that read kernel strings
Date: Wed, 07 Oct 2026 10:10:48 +0000 [thread overview]
Message-ID: <20261007101050.ED9881F0089C@smtp.kernel.org> (raw)
In-Reply-To: <20261006224005.49636-1-kylebot@openai.com>
On Tue, 06 Oct 2026 15:40:05 -0700, Kyle Zeng <kylebot@openai.com> wrote:
> A task-bound, counting-only syscall tracepoint can be opened without
> permission to read raw kernel tracepoint data. Setting exclude_kernel
> does not prevent its filter from running: perf_syscall_enter() submits
> the saved user-mode registers.
>
> Pointer-string filters use FILTER_PRED_FN_PCHAR by default, which reads
> through strncpy_from_kernel_nofault(). For sys_enter_openat, for example,
> the filename field comes directly from a syscall argument. An
> unprivileged caller can pass a kernel address, install a filter such as
> 'filename ~ "Linux version*"', and use the event count to test the
> contents of kernel memory, even with perf_event_paranoid=2.
>
> Check the compiled filter before installing it and require the same
> kernel and raw-tracepoint permissions as access to raw kernel tracepoint
> data for FILTER_PRED_FN_PCHAR. Inspect every predicate so that other
> events, operators, and boolean expressions cannot bypass the check.
> Return the permission error through the existing cleanup path before
> publishing the filter.
>
> Keep user-pointer (.ustring) and record-local predicates available under
> the existing policy. This leaves tracefs filtering and authorized kernel
> string filtering unchanged.
>
> Fixes: 5967bd5c4239 ("tracing: Let filter_assign_type() detect FILTER_PTR_STRING")
> Assisted-by: Codex:gpt-6-astra
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
Looks good to me.
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
prev parent reply other threads:[~2026-10-07 10:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 22:40 [PATCH] tracing: Restrict perf filters that read kernel strings Kyle Zeng
2026-10-07 10:10 ` Masami Hiramatsu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261007101050.ED9881F0089C@smtp.kernel.org \
--to=mhiramat@kernel.org \
--cc=kylebot@openai.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=outbounddisclosures@openai.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.