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

["Chen, Zide" <zide.chen@intel.com>]

On 4/13/2026 7:14 PM, Dapeng Mi wrote:
> Prior to the arch-LBR which supports CPL filtering, the kernel address
> could be leaked to user space even PERF_SAMPLE_BRANCH_USER is required.

This sounds correct to catch these branches, since only the target CPL
counts. The software filtering is implemented to match the HW behavior:

Legacy LBR.
CPL_EQ_0: When set, do not capture branches ending in ring 0
CPL_NEQ_0: When set, do not capture branches ending in ring >0

Arch LBR:
For operations which change the CPL, the operation is recorded in LBRs
only if the CPL at the end of the operation is enabled for LBR
recording. In cases where the CPL transitions from a value that is
filtered out to a value that is enabled for LBR
recording, the FROM_IP address for the recorded CPL transition branch or
event will be 0FFFFFFFFFFFFFFFFH.

> 
> e.g., run below command on Intel Tigerlake platform,
> 
> ```
> $./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \
>  	./perf bench syscall basic --loop 1000 | \
> 	./perf script -i - --fields brstack|tr ' ' '\n'| \
> 	grep -E '0x[89a-f][0-9a-f]{15}'
> 
>     Total time: 0.000 [sec]
> 
>       0.219000 usecs/op
>      4,566,210 ops/sec
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.551 MB - ]
> 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/-
> 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/-
> 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/-
> 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/-
> ```

Thus, filtering with USR=1, it's correct that ERET/SYSRET show up in the
above command running on TG because the target CPL is 3. However, the
from address should be hidden with 0xFFFFFFFFFFFFFFFF.

Instead, this appears a bug on platforms with CPL filtering (SPR, etc.)
that filters out these branches. This is because for ERET/SYSRET, the
br_type is 8 (OTHER_BRANCH), so even on arch LBR, it gets the type from
branch_type() which incorrectly translates type 8 to 0 (X86_BR_NONE).

Therefore, something needs to be done in get_branch_type() to handle
OTHER_BRANCH.

> The SYSRET/ERET branch calls are found the in the LBR stack, whose "from"
> addresses are obviously kernel address.
> 
> Currently intel_pmu_lbr_filter() only filters out the LBR entries whose
> "to" address is a kernel address but doesn't check the "from" address.
> 
> To fix the issue, extend the software filtering to both "from" and "to"
> addresses.
> 
> 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>
> ---
>  arch/x86/events/intel/lbr.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
> index 16977e4c6f8a..deef81c16571 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 */
> @@ -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))) {
>  			cpuc->lbr_entries[i].from = 0;
>  			compress = true;
>  		}