From: sashiko-bot@kernel.org
To: "Zhengchuan Liang" <zcliangcn@gmail.com>
Cc: linux-perf-users@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] perf/core: Restrict function predicates in trace event filters
Date: Fri, 02 Oct 2026 09:14:23 +0000 [thread overview]
Message-ID: <20261002091423.743201F00899@smtp.kernel.org> (raw)
In-Reply-To: <e66d86bf790ce51ca865c354a9b7a716c08b552f.1790891867.git.zcliangcn@gmail.com>
> Count-only perf tracepoint events can be opened without tracepoint
> permission because they do not expose raw sample data. Their
> PERF_EVENT_IOC_SET_FILTER ioctl can still pass filter expressions to the
> tracing parser.
>
> A .function operand makes the parser resolve either a numeric kernel
> address or a kernel symbol. The ioctl return value can therefore be used
> as an oracle to recover the randomized kernel text base.
>
> Trace events marked TRACE_EVENT_FL_CAP_ANY are different: task-local
> events may expose their raw fields to unprivileged users. Syscall
> tracepoints and uprobes deliberately use this exception, so denying every
> filter without tracepoint permission would break their ordinary filters.
>
> Check perf_allow_tracepoint() in perf. If permission is denied, continue
> only for a task-attached TRACE_EVENT_FL_CAP_ANY event whose filter does
> not contain an unquoted .function postfix. This rejects the predicate
> before the tracing parser can resolve either form of operand. The scan
> uses the parser's quote rules, so .function inside a string operand
> remains an ordinary filter value.
>
> This preserves ordinary filters on task-local events whose fields are
> already available to the caller, while non-CAP_ANY filters and kernel
> address resolution remain unavailable without tracepoint permission.
>
> Fixes: e6745a4da964 ("tracing: Add a way to filter function addresses to function names")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1790891867.git.zcliangcn@gmail.com?part=1
prev parent reply other threads:[~2026-10-02 9:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 23:46 [PATCH v2 0/1] perf/core: Prevent tracepoint filters from exposing the kernel text base Zhengchuan Liang
2026-10-01 23:46 ` [PATCH v2 1/1] perf/core: Restrict function predicates in trace event filters Zhengchuan Liang
2026-10-02 9:14 ` sashiko-bot [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=20261002091423.743201F00899@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zcliangcn@gmail.com \
/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.