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

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

On 6/5/2026 9:38 AM, sashiko-bot@kernel.org wrote:
> 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.

Yes, it's true. But since PEBS has no way to sample CS register and the
value of CS register can only come from the data of PMI. It seems no better
way except dropping all these register data from PEBS records. 


>
>> +		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?

Hmm, make sense. Need extra changes to prevent these 2 leakages.

Thanks.


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