Re: [PATCH] perf/x86/amd/lbr: Fix kernel address leakage

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] AMD's Branch Record Sampling (BRS) software filter shares the exact same logic flaw as AMD LBR V2, exposing kernel addresses when PERF_SAMPLE_BRANCH_USER is requested.
- [High] The Intel LBR software filter shares the same logic flaw, exposing kernel addresses on Intel CPUs that rely on software filtering.
--

--- Patch [1]: [PATCH] perf/x86/amd/lbr: Fix kernel address leakage ---
commit f8aba9338ad1990ca06ee1ac10089bd82793534b
Author: Sandipan Das <sandipan.das@amd.com>

perf/x86/amd/lbr: Fix kernel address leakage

A user-only branch stack can contain branches that originate from the kernel,
exposing kernel addresses to user space even when PERF_SAMPLE_BRANCH_USER
is requested. This commit extends software filtering on AMD processors
supporting X86_FEATURE_AMD_LBR_V2 to validate branch-from addresses against
the requested branch selection, dropping entries with kernel branch-from
addresses.

> diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
> index d24da377df776..b9722e60d8bc7 100644
> --- a/arch/x86/events/amd/lbr.c
> +++ b/arch/x86/events/amd/lbr.c
> @@ -125,7 +125,8 @@ static void amd_pmu_lbr_filter(void)
>  		}
>  
>  		/* If type does not correspond, then discard */
> -		if (type == X86_BR_NONE || (br_sel & type) != type) {
> +		if (type == X86_BR_NONE || (br_sel & type) != type ||
> +		    (!(br_sel & X86_BR_KERNEL) && kernel_ip(cpuc->lbr_entries[i].from))) {

[Severity: High]
This isn't a bug introduced by this patch, but does the AMD Branch Record
Sampling (BRS) software filter share this exact same logic flaw?

Looking at arch/x86/events/amd/brs.c:amd_brs_match_plm():

        if (!(type & plm_k) && kernel_ip(to))
                return false;

The software privilege filter evaluates only the target address (to) but
fails to validate the source address (from). When amd_brs_drain() reads
the unfiltered kernel 'from' address:

        rdmsrq(brs_from(brs_idx), from);

Could this allow kernel-to-user transitions to pass and leak kernel addresses
when PERF_SAMPLE_BRANCH_USER is requested?


[Severity: High]
This is also a pre-existing issue not introduced by this patch, but does the
Intel LBR software filter have the same vulnerability?

Looking at arch/x86/events/intel/lbr.c:intel_pmu_lbr_filter():

        to_plm = kernel_ip(to) ? X86_BR_KERNEL : X86_BR_USER;
        type = arch_lbr_br_type_map[type] | to_plm;

The branch type's privilege level is determined exclusively by the target
address (to), ignoring the source address (from). When it checks the type
later in the same function:

        if (type == X86_BR_NONE || (br_sel & type) != type) {
                cpuc->lbr_entries[i].from = 0;
                compress = true;
        }

It seems this would also fail to filter out kernel-to-user branches when
PERF_SAMPLE_BRANCH_USER is requested. Should similar software filtering
be applied there to validate the branch-from addresses?

>  			cpuc->lbr_entries[i].from = 0;	/* mark invalid */
>  			compress = true;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/a898a29725f6b2f30518354cdc2e432db66c43cf.1783680119.git.sandipan.das@amd.com?part=1