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

[sashiko-bot@kernel.org]

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?

[ ... ]

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


[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()?

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

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