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

[sashiko-bot@kernel.org]

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?

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