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

[sashiko-bot@kernel.org]

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?

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

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