From: sashiko-bot@kernel.org
To: "Anubhav Shelat" <ashelat@redhat.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2] perf: enable unprivileged syscall tracing with perf trace
Date: Fri, 10 Apr 2026 14:05:29 +0000 [thread overview]
Message-ID: <20260410140530.4F754C19421@smtp.kernel.org> (raw)
In-Reply-To: <20260410133529.21947-1-ashelat@redhat.com>
Sashiko AI review found 1 potential issue(s):
- [High] The kaddr_leak mask in perf_event_open() fails to block PERF_SAMPLE_IP and PERF_SAMPLE_REGS_INTR, allowing unprivileged users to bypass KASLR and leak kernel register state.
--
commit d9060ee10098244bcdd4bf26d128fe8ae6f9f578
Author: Anubhav Shelat <ashelat@redhat.com>
perf: enable unprivileged syscall tracing with perf trace
This patch allows unprivileged users to trace their own processes' syscalls
using perf trace by relaxing the perf_allow_kernel() check for task-attached
tracepoint events. It attempts to prevent KASLR bypasses by blocking sample
types that expose kernel addresses.
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 6d1f8bad7e1c5..07d67d95af96f 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -13833,9 +13833,25 @@ SYSCALL_DEFINE5(perf_event_open,
> return err;
>
> if (!attr.exclude_kernel) {
> - err = perf_allow_kernel();
> - if (err)
> - return err;
> + bool tp_bypass = false;
> +
> + if (attr.type == PERF_TYPE_TRACEPOINT && pid != -1) {
> + /*
> + * Block sample types that expose kernel addresses to
> + * prevent KASLR bypass
> + */
> + u64 kaddr_leak = PERF_SAMPLE_CALLCHAIN |
> + PERF_SAMPLE_BRANCH_STACK |
> + PERF_SAMPLE_ADDR;
Does this kaddr_leak mask need to include PERF_SAMPLE_IP and
PERF_SAMPLE_REGS_INTR?
If an unprivileged user requests a task-attached tracepoint event with
exclude_kernel=0 and specifies PERF_SAMPLE_IP or PERF_SAMPLE_REGS_INTR,
tp_bypass will evaluate to true and the perf_allow_kernel() check will be
skipped.
When the tracepoint fires in kernel mode, won't the user receive samples
containing the kernel instruction pointer and full CPU register state,
allowing a KASLR bypass?
> +
> + tp_bypass = !(attr.sample_type & kaddr_leak);
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260410133529.21947-1-ashelat@redhat.com?part=1
prev parent reply other threads:[~2026-04-10 14:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 13:35 [PATCH v2] perf: enable unprivileged syscall tracing with perf trace Anubhav Shelat
2026-04-10 14:05 ` 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=20260410140530.4F754C19421@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ashelat@redhat.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
/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.