Re: [Patch v2 5/9] perf/x86/intel: Drop LBR entries whose privilege level mismatches br_sel

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

On 6/9/2026 1:21 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The kernel address leak in LBR stacks fixed here for Intel PMUs still exists in AMD PMUs (both AMD LBR and AMD BRS), allowing KASLR bypass.
> --
>
> commit 955fb4f61b3305a8e4972ee94bb41e752a3dd25c
> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>
> perf/x86/intel: Drop LBR entries whose privilege level mismatches br_sel
>
> This commit fixes an issue where kernel branch addresses could be exposed
> to user space in user-only branch stacks. It extends the software filter
> in intel_pmu_lbr_filter() to validate both the from and to addresses
> against the requested branch privilege filter.
>
>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>> index 171fdf1962ade..9a63209cc7878 100644
>> --- a/arch/x86/events/intel/lbr.c
>> +++ b/arch/x86/events/intel/lbr.c
> [ ... ]
>
>> @@ -1246,8 +1246,16 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
>>  				type |= X86_BR_NO_TX;
>>  		}
>>  
>> -		/* if type does not correspond, then discard */
>> -		if (type == X86_BR_NONE || (br_sel & type) != type) {
>> +		from_plm = kernel_ip(from) ? X86_BR_KERNEL : X86_BR_USER;
>> +		/*
>> +		 * If type does not correspond, then discard.
>> +		 * Especially filter out the entries whose from or to address is
>> +		 * a kernel address while only X86_BR_USER is set. This prevents
>> +		 * kernel address from being leaked into a user-space-only LBR stack.
>> +		 */
>> +		if (type == X86_BR_NONE || (br_sel & type) != type ||
>> +		    (!(br_sel & X86_BR_KERNEL) && (from_plm & X86_BR_KERNEL)) ||
>> +		    (!(br_sel & X86_BR_USER) && (from_plm & X86_BR_USER))) {
>>  			cpuc->lbr_entries[i].from = 0;
>>  			compress = true;
>>  		}
> [Severity: High]
> This is a pre-existing issue, but does the AMD PMU code suffer from this
> same vulnerability?
>
> Looking at the AMD LBR software filter, it appears to only check the
> target privilege level and is missing the from_plm privilege validation:
>
> arch/x86/events/amd/lbr.c:amd_pmu_lbr_filter() {
>     ...
>     /* If type does not correspond, then discard */
>     if (type == X86_BR_NONE || (br_sel & type) != type) {
>         cpuc->lbr_entries[i].from = 0;  /* mark invalid */
>     ...
> }
>
> Similarly, the AMD BRS filter explicitly only validates the to address
> and ignores the from address:
>
> arch/x86/events/amd/brs.c:amd_brs_match_plm() {
>     ...
>     if (!(type & plm_k) && kernel_ip(to))
>         return 0;
>
>     if (!(type & plm_u) && !kernel_ip(to))
>         return 0;
>
>     return 1;
> }
>
> Could kernel addresses from kernel-to-user branches leak into user-space
> LBR stacks on AMD systems through these paths, bypassing KASLR in the
> same way?

Yes, this is a known issue and AMD guys would post the fixing patches
separately. Thanks.


>