From: sashiko-bot@kernel.org
To: "Dapeng Mi" <dapeng1.mi@linux.intel.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v2 9/9] perf/core: Check kernel access when kernel callchains are requested
Date: Tue, 09 Jun 2026 05:24:10 +0000 [thread overview]
Message-ID: <20260609052411.1CCD61F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260609050222.2458129-10-dapeng1.mi@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The patch breaks `perf record -g` for unprivileged users with existing `perf` binaries.
--
commit ac223ffdf5e79c1aa96a91deecdff94004bbe30f
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
perf/core: Check kernel access when kernel callchains are requested
This commit updates perf_event_open to verify kernel access permissions
when kernel callchains are requested, even if exclude_kernel is set.
This is intended to prevent unprivileged capture of kernel callchains.
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
[ ... ]
> @@ -13904,7 +13904,9 @@ SYSCALL_DEFINE5(perf_event_open,
> if (err)
> return err;
>
> - if (!attr.exclude_kernel) {
> + if (!attr.exclude_kernel ||
> + ((attr.sample_type & PERF_SAMPLE_CALLCHAIN) &&
> + !attr.exclude_callchain_kernel)) {
> err = perf_allow_kernel();
[Severity: Critical]
Does this change break perf record -g for unprivileged users using
existing perf binaries?
When an unprivileged user runs perf record -g, the initial syscall
request fails with -EACCES. The perf tool's existing fallback logic
retries by setting exclude_kernel = 1, but it leaves
exclude_callchain_kernel = 0.
Because this new check enforces the privilege requirement for callchains
even when exclude_kernel is set, the retried syscall will fail a second
time with -EACCES.
Looking at the perf tool's fallback handler:
tools/perf/util/evsel.c:evsel__fallback() {
...
} else if (err == EACCES && !evsel->core.attr.exclude_kernel &&
(paranoid = perf_event_paranoid()) > 1) {
...
}
Since exclude_kernel was set to 1 during the first fallback, the tool
cannot handle the second -EACCES failure. Will this cause the tool to
abort entirely with a permission denied error rather than falling back
to user-only callchains?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609050222.2458129-1-dapeng1.mi@linux.intel.com?part=9
next prev parent reply other threads:[~2026-06-09 5:24 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 5:02 [Patch v2 0/9] perf/x86: Miscellaneous PMU bug fixes Dapeng Mi
2026-06-09 5:02 ` [Patch v2 1/9] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities Dapeng Mi
2026-06-09 5:02 ` [Patch v2 2/9] perf/x86: Introduce is_x86_pmu() helper Dapeng Mi
2026-06-09 5:02 ` [Patch v2 3/9] perf/x86: Update cap_user_rdpmc base on rdpmc user disable state Dapeng Mi
2026-06-09 14:48 ` Peter Zijlstra
2026-06-10 1:47 ` Mi, Dapeng
2026-06-09 5:02 ` [Patch v2 4/9] perf/x86/intel: Fallback to sw branch type decoding if no hw decoding Dapeng Mi
2026-06-09 5:24 ` sashiko-bot
2026-06-09 10:04 ` Mi, Dapeng
2026-06-09 14:49 ` Peter Zijlstra
2026-06-10 1:53 ` Mi, Dapeng
2026-06-09 5:02 ` [Patch v2 5/9] perf/x86/intel: Drop LBR entries whose privilege level mismatches br_sel Dapeng Mi
2026-06-09 5:21 ` sashiko-bot
2026-06-09 9:40 ` Mi, Dapeng
2026-06-09 14:52 ` Peter Zijlstra
2026-06-10 1:57 ` Mi, Dapeng
2026-06-09 5:02 ` [Patch v2 6/9] perf/x86/intel: Validate return value of intel_pmu_init_hybrid() Dapeng Mi
2026-06-09 5:25 ` sashiko-bot
2026-06-09 9:44 ` Mi, Dapeng
2026-06-10 8:16 ` Peter Zijlstra
2026-06-10 8:34 ` Mi, Dapeng
2026-06-09 5:02 ` [Patch v2 7/9] perf/x86/intel: Drop fixed-counter PEBS constraints for baseline PEBS Dapeng Mi
2026-06-10 8:20 ` Peter Zijlstra
2026-06-10 8:23 ` Peter Zijlstra
2026-06-10 8:50 ` Mi, Dapeng
2026-06-10 11:21 ` Peter Zijlstra
2026-06-10 11:42 ` Mi, Dapeng
2026-06-10 22:22 ` Peter Zijlstra
2026-06-09 5:02 ` [Patch v2 8/9] perf/core: Fix kernel register info leak via hardware skid Dapeng Mi
2026-06-10 9:16 ` Peter Zijlstra
2026-06-09 5:02 ` [Patch v2 9/9] perf/core: Check kernel access when kernel callchains are requested Dapeng Mi
2026-06-09 5:24 ` sashiko-bot [this message]
2026-06-09 9:49 ` Mi, Dapeng
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=20260609052411.1CCD61F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dapeng1.mi@linux.intel.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@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.