Re: [PATCH 5/8] perf/x86/intel: Fix kernel address leakages in LBR stack

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

On 6/5/2026 9:33 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The exact same kernel address leak (KASLR bypass) vulnerability exists in the AMD LBR software filter (`amd_pmu_lbr_filter`), but the patch only fixes the Intel implementation.
> - [High] On Arch LBR CPUs that do not support hardware branch type decoding, the software filter incorrectly classifies all branches as conditional jumps (JCC).
> - [Medium] The software filter fails to drop branches executing in user space (e.g., SYSCALL) when only kernel branches are requested, diverging from hardware filter behavior.
> --
>
> commit e5f3b8c6179b0acb53df2e9f20348cf3b8f5a8be
> 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 LBR stack on Intel
> platforms prior to arch-LBR. It extends the software filtering in
> intel_pmu_lbr_filter() to check the "from" address privilege level,
> preventing kernel addresses from leaking to user space.
>
>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>> index 16977e4c6f8a5..deef81c16571a 100644
>> --- a/arch/x86/events/intel/lbr.c
>> +++ b/arch/x86/events/intel/lbr.c
>> @@ -1212,7 +1212,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
>>  {
>>  	u64 from, to;
>>  	int br_sel = cpuc->br_sel;
>> -	int i, j, type, to_plm;
>> +	int i, j, type, to_plm, from_plm;
>>  	bool compress = false;
>>  
>>  	/* if sampling all branches, then nothing to filter */
> [Severity: High]
> This is a pre-existing issue, but does this function correctly handle Arch
> LBR CPUs that do not support hardware branch type decoding?
>
> If an Arch LBR CPU does not support hardware branch type decoding
> (LBR_INFO.BR_TYPE), the x86_lbr_type static key remains false and
> get_lbr_br_type() returns 0.
>
> Earlier in intel_pmu_lbr_filter(), the code checks:
>
>     if (static_cpu_has(X86_FEATURE_ARCH_LBR) &&
>         type <= ARCH_LBR_BR_TYPE_KNOWN_MAX) {
>
> Since 0 <= 5 is always true, it maps arch_lbr_br_type_map[0] to X86_BR_JCC,
> bypassing the software decoding fallback in branch_type().
>
> Does this force all logged branches to be treated as conditional jumps on
> these processors, destroying branch filtering accuracy?

Yes, it's an issue. If arch-LBR can't support hardware branch type
decoding, it should fallback to software branch type decoding, like this,

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index deef81c16571..fcdbb6feda73 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1232,6 +1232,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
                 * OTHER_BRANCH branch type still rely on software decoding.
                 */
                if (static_cpu_has(X86_FEATURE_ARCH_LBR) &&
+                   static_branch_likely(&x86_lbr_type) &&
                    type <= ARCH_LBR_BR_TYPE_KNOWN_MAX) {
                        to_plm = kernel_ip(to) ? X86_BR_KERNEL : X86_BR_USER;
                        type = arch_lbr_br_type_map[type] | to_plm;


>
> [ ... ]
>
>> @@ -1244,8 +1244,15 @@ 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_PLM) == 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_PLM) == X86_BR_NONE || (br_sel & type) != type ||
>> +		    (!(br_sel & X86_BR_KERNEL) && (from_plm & X86_BR_KERNEL))) {
> [Severity: Medium]
> This is a pre-existing issue, but does this logic miss the symmetric check
> for scrubbing user-to-kernel branches from kernel-only samples?
>
> If a user requests only kernel branches (X86_BR_USER is not set), a SYSCALL
> (which goes from user to kernel) will be retained because the hardware
> filters based on destination CPL (kernel) and the software filter sees a
> valid to_plm.
>
> Should there be a check like:
>
>     (!(br_sel & X86_BR_USER) && (from_plm & X86_BR_USER))
>
> to prevent user-space addresses from polluting kernel-only branch traces?

Yes, this can be enhanced.


>
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does the exact same KASLR
> bypass vulnerability exist in the AMD LBR software filter?
>
> AMD's software filter in arch/x86/events/amd/lbr.c:amd_pmu_lbr_filter()
> uses branch_type_fused(), which only factors in the destination privilege
> level.
>
> When a user requests only user-space branches (PERF_SAMPLE_BRANCH_USER),
> hardware can still record kernel-to-user branches (like SYSRET) because
> the destination is in user space.
>
> Since the AMD filter evaluates (br_sel & type) == type as true based only
> on the destination, it keeps the branch, exposing the kernel "from" address
> to unprivileged userspace.
>
> Should a similar fix be applied to amd_pmu_lbr_filter()?

AMD guys have known this issue, the AMD specific fix would posted separately.

Thanks.


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