[PATCH AUTOSEL 6.18] perf/core: Fix kernel register info leak via hardware skid

[Sasha Levin <sashal@kernel.org>]

From: Dapeng Mi <dapeng1.mi@linux.intel.com>

[ Upstream commit 166f10836a653dfa280d4335603b52f685b8b1ef ]

An unprivileged hardware perf event using exclude_kernel=1 can leak kernel
register data to user space via PERF_SAMPLE_REGS_INTR or PERF_SAMPLE_IP.
Due to hardware skid, a PMI may trigger after the CPU has already entered
kernel space (Ring 0), bypassing the perf_allow_kernel() privilege
barrier.

This security vulnerability is severely exacerbated by upcoming support
for SIMD register sampling via XSAVES, which could expose sensitive kernel
FPU states (such as active cryptographic keys).

Fix this by ensuring that sampled register data is dropped if the event's
exclude_kernel attribute is set but the PMI catches the CPU in kernel mode.

Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/20260529085613.CCAFB1F00893@smtp.kernel.org/
Link: https://patch.msgid.link/20260616044654.3468742-8-dapeng1.mi@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have enough to decide: this is a real unprivileged kernel-register
leak on 6.18.53, and the fix is small enough to backport.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

Step 1.1: PARSE THE SUBJECT LINE
Record: [perf/core] [Fix] [Stop unprivileged hardware sampling from
leaking kernel IP/register state when PMI skid lands in Ring 0]

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> (author)
- Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
  (perf/core maintainer; merged into tip perf/core)
- Link: https://lore.kernel.org/all/20260529085613.CCAFB1F00893@smtp.ker
  nel.org/ (earlier discussion; lore fetch returned 403)
- Link: https://patch.msgid.link/20260616044654.3468742-8-
  dapeng1.mi@linux.intel.com (v4 series, this patch)
- No Fixes: tag (expected)
- No Cc: stable (expected)
- No Reported-by / Tested-by / Reviewed-by / Acked-by besides SOBs
- Ignore: Signed-off-by: Sasha Levin and "[Upstream commit
  166f10836a653dfa280d4335603b52f685b8b1ef]" (pipeline markers)

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- Bug: An unprivileged hardware perf event with `exclude_kernel=1` can
  still observe kernel register data through `PERF_SAMPLE_REGS_INTR` or
  `PERF_SAMPLE_IP`.
- Symptom/failure mode: Kernel IP and interrupt-time register state
  (GPRs; on some Intel platforms PEBS XMM too) are copied into the
  userspace mmap buffer. That is a KASLR / kernel-state info leak. The
  message also warns that later XSAVES SIMD sampling would make this
  worse (crypto-key material in FPU/SIMD state).
- Trigger: Hardware PMI skid: the overflow interrupt is delivered after
  the CPU has already entered kernel mode, so `perf_allow_kernel()` at
  `perf_event_open()` time is bypassed.
- Root cause: Sample preparation always dumps `regs` / IP from the PMI
  frame, with no check that `exclude_kernel` is consistent with
  `user_mode(regs)`.
- Versions: No kernel-version range in the message. The REGS_INTR dump
  path dates to 2014; guest IP helper to 2024.

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not a disguised cleanup. Subject and body state a security leak
and a surgical filter. Not a hidden bug.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

Step 2.1: INVENTORY THE CHANGES
Record:
- File: `kernel/events/core.c` (+30 / -7)
- Functions: `perf_instruction_pointer()`, `perf_sample_regs_intr()`,
  call site in `perf_prepare_sample()`
- Scope: single-file surgical fix

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- Hunk 1 (`perf_instruction_pointer`): Before, guest and host always
  returned the captured IP. After, if `exclude_kernel` and the captured
  context is not userspace (host `!user_mode(regs)`, or guest without
  `PERF_GUEST_USER`), IP is replaced with 0.
- Hunk 2 (`perf_sample_regs_intr`): Before, always `regs_intr->regs =
  regs` and a real ABI. After, if `exclude_kernel && !user_mode(regs)`,
  ABI is `PERF_SAMPLE_REGS_ABI_NONE` and `regs` is NULL so
  `perf_output_sample()` writes a zero ABI and skips register payload.
- Hunk 3 (`perf_prepare_sample`): Passes `event->attr.exclude_kernel`
  into the new parameter. Sample header size already accounts for a NULL
  `regs` pointer (`if (data->regs_intr.regs)`), so dyn_size stays
  consistent.

Step 2.3: IDENTIFY THE BUG MECHANISM
Record: Memory-safety / info-leak (unprivileged kernel-state
disclosure), not UAF/leak-of-heap.
- Mechanism: PMI skid + `exclude_kernel=1` still presents kernel
  `pt_regs` to userspace.
- Fix: Drop register payload and zero IP when the sample is kernel-mode
  but the event asked to exclude the kernel.
- Analogous to the 2017 attempt `cc1582c231ea0` ("Drop kernel samples
  even though :u is specified"), which was reverted in `6a8a75f323572`
  because dropping the whole sample broke rr overflow signals. This
  patch keeps the sample/signal and only redacts contents.

Step 2.4: ASSESS THE FIX QUALITY
Record:
- Obviously correct: the predicate matches the existing
  `sample_is_allowed()` / `perf_exclude_event()` tests (`exclude_kernel
  && !user_mode(regs)`).
- Minimal: three related sites, no API/UAPI change (ABI_NONE is the
  documented empty-regs encoding).
- Regression risk: low for kernel correctness. Userspace profilers can
  see IP=0 on skid samples; kernel test robot reported `perf-sanity-
  tests.Object_code_reading.fail` for that. Author said the kernel
  behavior is intended and the test should skip IP 0. rr is not broken
  because overflow still fires. Privileged `exclude_kernel=0` events are
  unchanged.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

Step 3.1: BLAME THE CHANGED LINES
Record:
- `perf_sample_regs_intr()` introduced by `60e2364e60e86e` (Stephane
  Eranian, 2014-11-16) "perf: Add ability to sample machine state on
  interrupt".
- `perf_instruction_pointer(event, regs)` guest split from
  `2c47e7a74f4454` / `04782e63917dbc` (Colton Lewis, 2024-11-13)
  "perf/core: Correct perf sampling with guest VMs".
- The leak of kernel IP on `:u` sampling has been a known class since at
  least 2017.

Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. Historical related commits:
- `cc1582c231ea0` (2017): dropped entire skid kernel samples; Cc:
  stable.
- `6a8a75f323572` (2017): reverted that because rr depends on overflow
  signals, not sample contents.
- `030a976efae83` (2022): reintroduced `sample_is_allowed()` only for
  sigtrap, not for sample output. In this tree it is used solely at
  `kernel/events/core.c:10445`.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record: Sibling security patches in the same Dapeng series (self-
contained, not prerequisites of this hunk):
- `perf/core: Check kernel access when kernel callchains are requested`
  (callchain permission hole)
- `perf/x86/intel: Fix kernel address leakages in LBR stack`
This patch does not need those to compile or to close the IP/REGS_INTR
hole.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Dapeng Mi is an Intel PMU/perf contributor. Peter Zijlstra
(subsystem maintainer) signed off and queued it on tip perf/core (commit
166f10836a653dfa280d4335603b52f685b8b1ef, 2026-06-30). Author's other
`kernel/events` work in this clone is unrelated cpu-clock fixes.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: Standalone. All symbols used (`user_mode`,
`PERF_SAMPLE_REGS_ABI_NONE`, `should_sample_guest`, `perf_guest_state`,
`PERF_GUEST_USER`, `perf_guest_get_ip`) exist in v6.18.53. Signature
change of static `perf_sample_regs_intr()` has a single call site in
`core.c`.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- b4 dig matched patch-id to lore; msgid
  `20260616044654.3468742-8-dapeng1.mi@linux.intel.com`
- Evolved from the v8 SIMD/XSAVES sampling series (2026-05-29) into a
  standalone "miscellaneous PMU bug fixes" series:
  - v1 2026-06-05: only `perf_sample_regs_intr` (no IP redaction)
  - v2–v4: added `perf_instruction_pointer` host+guest IP redaction
    (committed form)
- Merged to tip perf/core 2026-06-30 by Peter Zijlstra; no NAK found.
- Later (2026-09-15) kernel test robot: userspace `Object code reading`
  test fails on IP 0. Dapeng: expected; test should filter IP 0. That is
  not a kernel functional/security regression.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record: Recipients (b4 dig -w): Peter Zijlstra, Ingo Molnar, Arnaldo
Carvalho de Melo, Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander
Shishkin, Andi Kleen, Stephane Eranian, Mark Rutland, linux-kernel,
linux-perf-users. Maintainer SOB is the strongest review signal found.
Lore HTML itself returned 403; discussion reconstructed from
openwall/lkml mirrors.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No syzbot/bugzilla. Motivated by analysis around SIMD register
sampling. The IP leak is independently real: unprivileged `perf record
-e cycles:u` is a common path, and 2017 already treated skid kernel
samples as a security issue.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Same series also has callchain permission and LBR address-leak
fixes. Those are separate holes. This commit does not depend on
SIMD/XSAVES patches; v6.18.53 has no XSAVES SIMD sampling (`git grep` of
XSAVES SIMD sample paths on v6.18.53 was empty). XMM-via-PEBS already
exists on Ice Lake+ (`PERF_REG_EXTENDED_MASK` in
`arch/x86/events/core.c`).

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: lore.kernel.org/stable search returned 403. No evidence this was
rejected for stable. Absence of Cc: stable is expected for this review
pipeline.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: `perf_instruction_pointer`, `perf_sample_regs_intr`,
`perf_prepare_sample`. Related existing helpers: `sample_is_allowed`,
`perf_allow_kernel`, `perf_output_sample`.

Step 5.2: TRACE CALLERS
Record:
- `perf_instruction_pointer()`: only used from `perf_prepare_sample()`
  (`data->ip = ...`) when `PERF_SAMPLE_IP` (or dependent
  `PERF_SAMPLE_CODE_PAGE_SIZE`) is set.
- `perf_sample_regs_intr()`: only called from `perf_prepare_sample()`
  for `PERF_SAMPLE_REGS_INTR`.
- `perf_prepare_sample()`: `__perf_event_output()` (normal mmap
  samples), `bpf_overflow_handler()`, PEBS/BTS/s390 sampling paths.
  Hardware PMI → `perf_event_overflow()` → overflow handler → output.
  Confirmed `__perf_event_overflow()` does **not** drop skid kernel
  samples today; `sample_is_allowed()` is sigtrap-only.

Step 5.3: TRACE CALLEES
Record: `user_mode(regs)`, `perf_arch_instruction_pointer()`,
`perf_guest_get_ip()`, `perf_guest_state()`, `perf_reg_abi()`. Output
path: `perf_output_sample()` already treats ABI 0 as "no regs".

Step 5.4: FOLLOW THE CALL CHAIN
Record: Reachable from unprivileged `perf_event_open()`:
- `sysctl_perf_event_paranoid > 1` requires `exclude_kernel=1`
  (`perf_allow_kernel()` at `kernel/events/core.c:13553`).
- `PERF_SAMPLE_IP` has no extra privilege check (default sample type).
- `PERF_SAMPLE_REGS_INTR` is gated only by
  `security_locked_down(LOCKDOWN_PERF)`, not paranoid. Without lockdown
  (typical without Secure Boot), unprivileged REGS_INTR is allowed.
Trigger is common: non-precise `cycles:u` around syscalls/page faults.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Same `exclude_kernel && !user_mode(regs)` already used in
`sample_is_allowed()`, `perf_exclude_event()`, and tracepoint matching.
This patch extends that policy to sample payload. Remaining sibling
holes (callchain, LBR) are other commits.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record: Yes. Local tree is **6.18.53** (`git describe HEAD` =
`v6.18.53-5049-g0f0bdc2b0dffb`, Makefile VERSION=6 PATCHLEVEL=18
SUBLEVEL=53). At tag `v6.18.53`:
- `perf_instruction_pointer` returns guest/host IP unconditionally.
- `perf_sample_regs_intr(regs)` always assigns `regs`.
- Call site is `perf_sample_regs_intr(&data->regs_intr, regs);`
- `git merge-base --is-ancestor 166f10836a653dfa280d4335603b52f685b8b1ef
  v6.18.53` is false.

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: Clean apply expected. Pre-image of both functions and the call
site on v6.18.53 matches the patch. `PERF_GUEST_USER` is in
`include/linux/perf_event.h`. No conflicting refactor of these functions
on 6.18.y.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: The 2017 full-sample drop is **not** present (reverted).
`sample_is_allowed()` does not redact IP/REGS_INTR. No other in-tree
substitute for this leak on 6.18.53.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: [perf/core, `kernel/events/core.c`] [CORE for
observability/security: `perf_event_open` is a common unprivileged
syscall; leak is kernel-wide, not driver-specific]

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Actively maintained (Peter Zijlstra). File still receives
UAF/deadlock fixes on 6.18.y; these two functions have been stable for
years.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

Step 8.1: DETERMINE WHO IS AFFECTED
Record: Any unprivileged user who can open a hardware sampling event
with `exclude_kernel=1` (default paranoid). Universal on systems with a
hardware PMU. REGS_INTR extra impact depends on lockdown; IP leak does
not.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record: Common. Non-precise userspace-only sampling (`cycles:u`) plus
kernel entry/exit. Unprivileged-triggerable. Timing-dependent (skid) but
well documented and previously reproduced in 2017.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: [Kernel address / register info leak, KASLR bypass; on PEBS XMM
also SIMD state] [Severity: HIGH / security. Not a panic. XSAVES full-
SIMD crypto-key leak is **not** in 6.18; XMM PEBS already is.]

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- Benefit: HIGH — closes an unprivileged kernel-IP leak on a default
  sampling path; also covers REGS_INTR.
- Risk: LOW — ~30 lines, static helper, keeps overflow (rr-safe),
  existing ABI_NONE encoding.
- Residual: userspace tools may see IP=0 (test already did). That is the
  security behavior, not a kernel crash.
- Ratio: strongly favors backport.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

Step 9.1: COMPILE THE EVIDENCE
FOR:
- Real unprivileged info leak via PMI skid; same class previously sent
  to stable in 2017.
- Current code on 6.18.53 still emits kernel IP/regs;
  `sample_is_allowed()` no longer drops samples.
- Surgical, obviously correct, maintainer-signed, applies cleanly.
- Avoids the rr regression by redacting payload instead of dropping the
  event.

AGAINST:
- Userspace perf "object code reading" test can fail on IP 0 (author:
  fix the test).
- No Fixes:/Cc:stable (not a negative per rules).
- XSAVES SIMD exacerbation is not in 6.18; the IP/GPR (and PEBS XMM)
  leak still is.

UNRESOLVED:
- Full lore HTML was 403; review reconstructed from mirrors and b4.
  Peter Zijlstra SOB still verified.
- Whether a userspace-only test fix later landed is unverified in this
  clone; it does not block the kernel fix.

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? PASS — maintainer merged; robot only
   hit expected IP=0.
2. Fixes a real bug that affects users? PASS — unprivileged
   `perf_event_open` + hardware sampling.
3. Important issue (crash, security, corruption, deadlock)? PASS —
   security info leak / KASLR.
4. Small and contained? PASS — one file, +30/-7.
5. No new features or APIs? PASS.
6. Can apply to the local tree? PASS — v6.18.53 pre-image matches.

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: Not a device-ID/quirk/DT/build/docs exception. Ordinary security
bugfix.

Step 9.4: MAKE YOUR DECISION
This tree is 6.18.53. The buggy dump path is present. The patch is a
small, rr-safe security fix with no missing prerequisites. It should be
backported.

------------------------------------------------
What the commit solves for stable users
Unprivileged hardware sampling with `exclude_kernel=1` can still capture
kernel IP and interrupt registers when the PMI skids into Ring 0. On
6.18 that includes default `PERF_SAMPLE_IP` and, unless lockdown,
`PERF_SAMPLE_REGS_INTR` (including PEBS XMM on capable Intel CPUs). The
fix redacts that payload without dropping the sample, so overflow-based
tools keep working.

Risk vs benefit
Benefit is a real KASLR/register leak on a common syscall path. Risk is
low: tiny core.c change, existing empty-regs ABI, no locking/API change.
The only observed fallout is userspace seeing IP 0, which is intended.

Concerns
No series dependencies for this hunk. XSAVES SIMD is not in 6.18; that
does not reduce the IP leak. A follow-up is only needed for the perf
selftest, not for kernel correctness.

Verification:
- [Phase 1] Parsed tags: Dapeng Mi author, Peter Zijlstra SOB, two
  lore/msgid links; no Fixes/Reported-by
- [Phase 2] Diff: `perf_instruction_pointer` zeros IP;
  `perf_sample_regs_intr` uses ABI_NONE; `perf_prepare_sample` passes
  `exclude_kernel`
- [Phase 3] `git blame v6.18.53`: REGS_INTR dump from `60e2364e60e86e`
  (2014); guest IP from `2c47e7a74f4454` (2024)
- [Phase 3] `git log -S sample_is_allowed -- kernel/events/core.c`: 2017
  drop reverted; current use is sigtrap-only
- [Phase 3] `git show 6a8a75f323572`: revert because rr needs overflow
  signals
- [Phase 4] `b4 dig -c 7db4d13613f57`: matched v4 msgid
  20260616044654.3468742-8; recipients include Peter Zijlstra et al.
- [Phase 4] `b4 dig -a`: originated in SIMD series v8, then standalone
  bugfix series v1–v4; IP redaction added after v1
- [Phase 4] openwall 2026-09-15: author confirms IP=0 is the leak fix;
  test should skip it
- [Phase 5] grep: `perf_instruction_pointer` / `perf_sample_regs_intr`
  only used from `perf_prepare_sample`; overflow path does not drop skid
  samples
- [Phase 5] `perf_allow_kernel()` at open requires `exclude_kernel` for
  unprivileged users; REGS_INTR only checks lockdown
- [Phase 6] `git describe HEAD` / Makefile: 6.18.53; v6.18.53 still has
  the unfiltered dump; ancestor check of 166f10836a65 vs v6.18.53 is
  false
- [Phase 6] `PERF_GUEST_USER` present; function pre-image matches patch
- [Phase 6] no XSAVES SIMD sampling in v6.18.53; XMM PEBS already
  present
- [Phase 8] Failure mode: unprivileged kernel IP/register disclosure,
  HIGH security
- UNVERIFIED: full lore.kernel.org thread body (HTTP 403); stable@ list
  search (403)

**YES**

 kernel/events/core.c | 37 ++++++++++++++++++++++++++++++-------
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 018a1e4ef5b0d..3b01c2853d681 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7499,10 +7499,20 @@ unsigned long perf_misc_flags(struct perf_event *event,
 unsigned long perf_instruction_pointer(struct perf_event *event,
 				       struct pt_regs *regs)
 {
-	if (should_sample_guest(event))
-		return perf_guest_get_ip();
+	/*
+	 * Hardware skid can lead to a scenario where a PMI is
+	 * delivered after the CPU has already entered kernel mode.
+	 * In that case, user-space sampling must not expose kernel
+	 * register state.
+	 */
+	if (should_sample_guest(event)) {
+		return event->attr.exclude_kernel &&
+		       !(perf_guest_state() & PERF_GUEST_USER) ?
+			0 : perf_guest_get_ip();
+	}
 
-	return perf_arch_instruction_pointer(regs);
+	return event->attr.exclude_kernel && !user_mode(regs) ?
+		0 : perf_arch_instruction_pointer(regs);
 }
 
 static void
@@ -7536,10 +7546,22 @@ static void perf_sample_regs_user(struct perf_regs *regs_user,
 }
 
 static void perf_sample_regs_intr(struct perf_regs *regs_intr,
-				  struct pt_regs *regs)
+				  struct pt_regs *regs,
+				  bool exclude_kernel)
 {
-	regs_intr->regs = regs;
-	regs_intr->abi  = perf_reg_abi(current);
+	/*
+	 * Hardware skid can lead to a scenario where a PMI is
+	 * delivered after the CPU has already entered kernel mode.
+	 * In that case, user-space sampling must not expose kernel
+	 * register state.
+	 */
+	if (exclude_kernel && !user_mode(regs)) {
+		regs_intr->abi = PERF_SAMPLE_REGS_ABI_NONE;
+		regs_intr->regs = NULL;
+	} else {
+		regs_intr->regs = regs;
+		regs_intr->abi = perf_reg_abi(current);
+	}
 }
 
 
@@ -8427,7 +8449,8 @@ void perf_prepare_sample(struct perf_sample_data *data,
 		/* regs dump ABI info */
 		int size = sizeof(u64);
 
-		perf_sample_regs_intr(&data->regs_intr, regs);
+		perf_sample_regs_intr(&data->regs_intr, regs,
+				      event->attr.exclude_kernel);
 
 		if (data->regs_intr.regs) {
 			u64 mask = event->attr.sample_regs_intr;
-- 
2.53.0