Re: [PATCH 8/8] perf/core: Fix kernel register info leak via hardware skid

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Valid hardware-captured user-space register samples from precise events (e.g., Intel PEBS) are incorrectly dropped as sensitive kernel data when the PMU interrupt (PMI) skids into kernel mode.

Pre-existing issues:
- [High] Hardware PMI skid still leaks kernel IPs and callchains to unprivileged users when exclude_kernel=1.
--

commit 8a7df272a8b8797c3525f28de5158f11f610df4d
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>

perf/core: Fix kernel register info leak via hardware skid
    
This patch addresses a security vulnerability where hardware skid can
cause a PMI to trigger in kernel space, leaking kernel register data
to user space via PERF_SAMPLE_REGS_INTR. It fixes this by dropping
sampled register data if the event has exclude_kernel set but the CPU
is in kernel mode.
    
Link: https://lore.kernel.org/all/20260529085613.CCAFB1F00893@smtp.kernel.org/

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 7935d5663944e..b7326bc3acd00 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -7800,10 +7800,21 @@ 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 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)) {

[Severity: High]
Will this incorrectly drop valid hardware-captured user-space register
samples from precise events like Intel PEBS?

For precise events, the PMU driver populates a temporary pt_regs
with exact user-space registers captured by the hardware. Because PEBS
does not capture segment registers, the driver copies them from the
delayed PMI interrupt context:

arch/x86/events/intel/ds.c:setup_pebs_fixed_sample_data() {
    *regs = *iregs;
    ...
}

If the PMI skids and is delivered after the CPU enters kernel space,
iregs->cs reflects kernel mode, causing user_mode(regs) to evaluate
to false. This would result in these safe, hardware-captured user
registers being zeroed out here, which seems like it might break
unprivileged precise profiling.

> +		regs_intr->abi = PERF_SAMPLE_REGS_ABI_NONE;
> +		regs_intr->regs = NULL;
> +	} else {
> +		regs_intr->regs = regs;
> +		regs_intr->abi = perf_reg_abi(current);
> +	}
>  }

[ ... ]

> @@ -8694,7 +8705,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);

[Severity: High]
This is a pre-existing issue, but does the hardware PMI skid still leak
kernel IPs and callchains to unprivileged users when exclude_kernel=1?

While this patch correctly zeroes out the register state to prevent
leaking the full CPU register context, it appears the same privilege
boundaries are not applied to PERF_SAMPLE_IP and PERF_SAMPLE_CALLCHAIN.

In perf_prepare_sample(), the kernel IP is unconditionally extracted
from regs if the PMI skid caught the CPU in kernel mode:

kernel/events/core.c:perf_prepare_sample() {
    if (filtered_sample_type & PERF_SAMPLE_IP) {
        data->ip = perf_instruction_pointer(event, regs);
        ...
    }
}

Similarly, unprivileged users can set exclude_kernel=1 and leave
exclude_callchain_kernel=0. On a skid, !user_mode(regs) evaluates to
true, causing perf_callchain() to unwind and expose the kernel stack
trace.

Could this allow a deterministic KASLR bypass, and should it be
addressed alongside the register clearing?

>  
>  		if (data->regs_intr.regs) {
>  			u64 mask = event->attr.sample_regs_intr;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605011136.2043393-1-dapeng1.mi@linux.intel.com?part=8