Re: [Patch v3 4/8] perf/x86/intel: Fix kernel address leakages in LBR stack

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

On 6/12/2026 5:18 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] Missing Privilege Escalation/Leakage Fix in AMD LBR
> --
>
> commit c04d9132d61b165193dd28c5a358e42d3c52a350
> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>
> perf/x86/intel: Fix kernel address leakages in LBR stack
>
> This commit fixes a kernel address leakage in the Intel LBR stack when
> PERF_SAMPLE_BRANCH_USER is requested. The intel_pmu_lbr_filter function
> previously only validated the privilege level of the "to" address, leaving
> kernel "from" addresses exposed on SYSRET/ERET branches. The fix extends
> software filtering to validate both addresses against the requested filter.
>
> Cc: stable@vger.kernel.org
> Reported-by: Ian Rogers <irogers@google.com>
> Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>
>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>> index e2657f791e507..16eef15378166 100644
>> --- a/arch/x86/events/intel/lbr.c
>> +++ b/arch/x86/events/intel/lbr.c
> [ ... ]
>
>> @@ -1244,8 +1244,14 @@ 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.
>> +		 * Specifically reject entries whose from address is in
>> +		 * kernel space when only X86_BR_USER is requested.
>> +		 */
>> +		if (type == X86_BR_NONE || (br_sel & type) != type ||
>> +		    (!(br_sel & X86_BR_KERNEL) && (from_plm & X86_BR_KERNEL))) {
> [Severity: High]
> This isn't a bug introduced by this patch, but does the exact same kernel
> address leakage vulnerability exist in AMD's LBR implementation and remain
> unpatched?
>
> Looking at amd_pmu_lbr_filter() in arch/x86/events/amd/lbr.c, it relies on
> branch_type_fused() to determine the branch type. For kernel-to-user branches
> (like SYSRET), it evaluates the privilege purely based on the target (to)
> address and returns X86_BR_SYSRET | X86_BR_USER.
>
> When user-only branches are requested, br_sel includes X86_BR_USER and
> X86_BR_ANY. Because AMD hardware will record kernel-to-user branches when
> filtering by "ending in CPL > 0", the check in amd_pmu_lbr_filter():
>
>     if (type == X86_BR_NONE || (br_sel & type) != type) {
>         cpuc->lbr_entries[i].from = 0;
>         compress = true;
>     }
>
> evaluates to false since type is fully satisfied by br_sel. This allows the
> branch to bypass the software filter and leaks the kernel from addresses to
> unprivileged users.
>
> Should a similar from_plm validation check be added to amd_pmu_lbr_filter()
> to prevent KASLR bypass on AMD systems?

AMD guys have known the issue, suppose they would post the fix separately.
Thanks.


>
>>  			cpuc->lbr_entries[i].from = 0;
>>  			compress = true;
>>  		}