Re: [Patch v4 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] The kernel address leak fixed in Intel LBR is also present in the AMD LBR and AMD BRS implementations.
--

commit 6e58211ef4792cdee63b678a385b927eb7214af9
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>

perf/x86/intel: Fix kernel address leakages in LBR stack

This commit fixes an information leak in Intel LBR where the software filter
failed to validate the from address. By validating both the from and to
addresses against the requested privilege mask, it prevents kernel addresses
from leaking into user-only branch stacks.

> 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 same kernel address
leak exist in the AMD LBR and BRS implementations?

Looking at arch/x86/events/amd/lbr.c, the software filter sets the branch
privilege strictly based on the target address. Kernel-to-user branches might
bypass the filter and leak the kernel from address:

arch/x86/events/amd/lbr.c:amd_pmu_lbr_filter() {
    ...
    type = branch_type_fused(from, to, 0, &offset);

    /* If type does not correspond, then discard */
    if (type == X86_BR_NONE || (br_sel & type) != type) {
    ...
}

Similarly, in arch/x86/events/amd/brs.c, the privilege filter only evaluates
the target address against the requested privilege mask:

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;
}

Because the hardware PMU natively records branches going from kernel space to
user space, could unprivileged users requesting user-only branches still
sample kernel addresses on AMD through these paths?

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

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