From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFC3C30F816; Tue, 14 Apr 2026 02:19:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776133164; cv=none; b=srjpRa2HQhAL6oem206t9te4kSWWauOK8mWW+Twq5/uWyJs5o6g3zWYsepjaXGfE6WIfcFQaezGy7y/kimzQRDl+QAu3fSFGpgYQVbLpFHd4k+su0FZaDnRV3sECCGqDqq1EAdmgv6os6DtLIKx6WbXPlydbWB4EWXf4R/eXe7A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776133164; c=relaxed/simple; bh=BeGev7zyMc7Af2WenC2i1TOYCrVAKkS/D9EO7cHARqs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=E/v3wwPnEkyPVHWGBPbCO8w66bKWhTDSL61bjMT5ziWxdAc29NF+8NeyqyPOZSRH4X86DMJ/vHnaCFjjECFzw+5TeBvc0yN7oBO/R8lMCcwTUEgVOYi2Vgp2q+aY5CTxpaRY5qHS3ExsVusx1gtlw7cJLtjz2FWALg6scf4EhQw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=RO62Vijr; arc=none smtp.client-ip=192.198.163.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="RO62Vijr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776133163; x=1807669163; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=BeGev7zyMc7Af2WenC2i1TOYCrVAKkS/D9EO7cHARqs=; b=RO62VijriYt3tzr0thq7lkiXWBC3jGHG00Zj8hDR+aAfNbTFL7nfrdsz pmAxWt4VSMROQgWam2DjN7uFpT0WMtWCiHvKLKU53mI0j3Ji17wvzWEFe Qo9kRyn6jqnMKYPtHIrrGc1o/AQ0QypG8QZkH+k+QrCKwerw7f9KESSxn dfumBK3iaBrr9AKTAutaoICjT+ckVW/rTZgYp+UWoRphX55wgGvrcNoQX m9Re7VpSHgBaVPKFHZomAW01k1ww8rDTs93Ff48XIEqAwoDdMxJM8puWF l5H3VB0kLXz9R8A9IWQWBREuatI751/OOnIvQ4yDmEeeFo4lHTJUP32DW A==; X-CSE-ConnectionGUID: h7yA1fS1THqxxD72M38N9w== X-CSE-MsgGUID: goX3GzH2RQeqgZ/YHWduzg== X-IronPort-AV: E=McAfee;i="6800,10657,11758"; a="76245477" X-IronPort-AV: E=Sophos;i="6.23,178,1770624000"; d="scan'208";a="76245477" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2026 19:19:23 -0700 X-CSE-ConnectionGUID: pw/xNrV4Tc6JXAU9pLtY7w== X-CSE-MsgGUID: SGFIzgCMQT2FHglGK0PoJg== X-ExtLoop1: 1 Received: from spr.sh.intel.com ([10.112.229.196]) by fmviesa003.fm.intel.com with ESMTP; 13 Apr 2026 19:19:19 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi , stable@vger.kernel.org Subject: [PATCH 2/2] perf/x86/intel: Fix kernel address leakages in LBR stack Date: Tue, 14 Apr 2026 10:14:40 +0800 Message-Id: <20260414021440.928068-2-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260414021440.928068-1-dapeng1.mi@linux.intel.com> References: <20260414021440.928068-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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. 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/- ``` 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 Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Signed-off-by: Dapeng Mi --- 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; } -- 2.34.1