* [PATCH] perf/x86/intel: Fix KASAN global-out-of-bounds warning
@ 2025-09-04 1:24 Dapeng Mi
2025-10-23 17:45 ` Chen, Zide
0 siblings, 1 reply; 3+ messages in thread
From: Dapeng Mi @ 2025-09-04 1:24 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Kan Liang, Andi Kleen, Eranian Stephane
Cc: linux-kernel, linux-perf-users, Dapeng Mi, Dapeng Mi, Xudong Hao,
stable
When running "perf mem record" command on CWF, the below KASAN
global-out-of-bounds warning is seen.
196.273657] ==================================================================
[ 196.273662] BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0
[ 196.273669] Read of size 4 at addr ffffffffb721d000 by task dtlb/9850
[ 196.273676] CPU: 126 UID: 0 PID: 9850 Comm: dtlb Kdump: loaded Not tainted 6.17.0-rc3-2025-08-29-intel-next-34160-g316938187eb0 #1 PREEMPT(none)
[ 196.273680] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P83.2507110208 07/11/2025
[ 196.273682] Call Trace:
[ 196.273683] <NMI>
[ 196.273684] dump_stack_lvl+0x55/0x70
[ 196.273689] print_address_description.constprop.0+0x2c/0x3d0
[ 196.273694] ? cmt_latency_data+0x176/0x1b0
[ 196.273696] print_report+0xb4/0x270
[ 196.273699] ? kasan_addr_to_slab+0xd/0xa0
[ 196.273702] kasan_report+0xb8/0xf0
[ 196.273705] ? cmt_latency_data+0x176/0x1b0
[ 196.273707] cmt_latency_data+0x176/0x1b0
[ 196.273710] setup_arch_pebs_sample_data+0xf49/0x2560
[ 196.273713] intel_pmu_drain_arch_pebs+0x577/0xb00
[ 196.273716] ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10
[ 196.273719] ? perf_output_begin+0x3e4/0xa10
[ 196.273724] ? intel_pmu_drain_bts_buffer+0xc2/0x6a0
[ 196.273727] ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10
[ 196.273730] handle_pmi_common+0x6c4/0xc80
[ 196.273734] ? __pfx_handle_pmi_common+0x10/0x10
[ 196.273738] ? intel_bts_interrupt+0xd3/0x4d0
[ 196.273740] ? __pfx_intel_bts_interrupt+0x10/0x10
[ 196.273742] ? intel_pmu_lbr_enable_all+0x25/0x150
[ 196.273745] intel_pmu_handle_irq+0x388/0x700
[ 196.273748] perf_event_nmi_handler+0xff/0x150
[ 196.273751] nmi_handle.part.0+0xa8/0x2d0
[ 196.273755] ? perf_output_begin+0x3e9/0xa10
[ 196.273757] default_do_nmi+0x79/0x1a0
[ 196.273760] fred_exc_nmi+0x40/0x90
[ 196.273762] asm_fred_entrypoint_kernel+0x45/0x60
[ 196.273765] RIP: 0010:perf_output_begin+0x3e9/0xa10
[ 196.273768] Code: 54 24 1c 85 d2 0f 85 19 03 00 00 48 8b 44 24 18 48 c1 e8 03 42 0f b6 04 28 84 c0 74 08 3c 03 0f 8e 25 05 00 00 41 8b 44 24 18 <c1> e0 0c 48 98 48 83 e8 01 80 7c 24 2a 00 0f 85 f9 02 00 00 4c 29
[ 196.273770] RSP: 0018:ffffc9001cf575e8 EFLAGS: 00000246
[ 196.273774] RAX: 0000000000000080 RBX: ffff88c1a0f95028 RCX: 0000000000000004
[ 196.273775] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88c08c8f9408
[ 196.273777] RBP: 0000000000000028 R08: 0000000000000000 R09: ffffed18341f2a05
[ 196.273778] R10: ffff88c1a0f9502f R11: ffff88c1a0dbe1b8 R12: ffff88c1a0f95000
[ 196.273779] R13: dffffc0000000000 R14: 0000000000000000 R15: ffffc9001cf577e0
[ 196.273782] </NMI>
The issue is caused by below code in __grt_latency_data(). The code
tries to access x86_hybrid_pmu structure which doesn't exist on
non-hybrid platform like CWF.
WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)
So add is_hybrid() check before calling this WARN_ON_ONCE to fix the
global-out-of-bounds access issue.
Reported-by: Xudong Hao <xudong.hao@intel.com>
Cc: stable@vger.kernel.org
Fixes: 090262439f66 ("perf/x86/intel: Rename model-specific pebs_latency_data functions")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
arch/x86/events/intel/ds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index c0b7ac1c7594..d1ac1f1ceee9 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -317,7 +317,7 @@ static u64 __grt_latency_data(struct perf_event *event, u64 status,
{
u64 val;
- WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big);
+ WARN_ON_ONCE(is_hybrid() && hybrid_pmu(event->pmu)->pmu_type == hybrid_big);
dse &= PERF_PEBS_DATA_SOURCE_GRT_MASK;
val = hybrid_var(event->pmu, pebs_data_source)[dse];
base-commit: 16ed389227651330879e17bd83d43bd234006722
--
2.34.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] perf/x86/intel: Fix KASAN global-out-of-bounds warning
2025-09-04 1:24 [PATCH] perf/x86/intel: Fix KASAN global-out-of-bounds warning Dapeng Mi
@ 2025-10-23 17:45 ` Chen, Zide
2025-10-24 0:37 ` Mi, Dapeng
0 siblings, 1 reply; 3+ messages in thread
From: Chen, Zide @ 2025-10-23 17:45 UTC (permalink / raw)
To: Dapeng Mi, Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Kan Liang, Andi Kleen, Eranian Stephane
Cc: linux-kernel, linux-perf-users, Dapeng Mi, Xudong Hao, stable
On 9/3/2025 6:24 PM, Dapeng Mi wrote:
> When running "perf mem record" command on CWF, the below KASAN
> global-out-of-bounds warning is seen.
>
> 196.273657] ==================================================================
> [ 196.273662] BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0
> [ 196.273669] Read of size 4 at addr ffffffffb721d000 by task dtlb/9850
>
> [ 196.273676] CPU: 126 UID: 0 PID: 9850 Comm: dtlb Kdump: loaded Not tainted 6.17.0-rc3-2025-08-29-intel-next-34160-g316938187eb0 #1 PREEMPT(none)
> [ 196.273680] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P83.2507110208 07/11/2025
> [ 196.273682] Call Trace:
> [ 196.273683] <NMI>
> [ 196.273684] dump_stack_lvl+0x55/0x70
> [ 196.273689] print_address_description.constprop.0+0x2c/0x3d0
> [ 196.273694] ? cmt_latency_data+0x176/0x1b0
> [ 196.273696] print_report+0xb4/0x270
> [ 196.273699] ? kasan_addr_to_slab+0xd/0xa0
> [ 196.273702] kasan_report+0xb8/0xf0
> [ 196.273705] ? cmt_latency_data+0x176/0x1b0
> [ 196.273707] cmt_latency_data+0x176/0x1b0
> [ 196.273710] setup_arch_pebs_sample_data+0xf49/0x2560
> [ 196.273713] intel_pmu_drain_arch_pebs+0x577/0xb00
> [ 196.273716] ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10
> [ 196.273719] ? perf_output_begin+0x3e4/0xa10
> [ 196.273724] ? intel_pmu_drain_bts_buffer+0xc2/0x6a0
> [ 196.273727] ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10
> [ 196.273730] handle_pmi_common+0x6c4/0xc80
> [ 196.273734] ? __pfx_handle_pmi_common+0x10/0x10
> [ 196.273738] ? intel_bts_interrupt+0xd3/0x4d0
> [ 196.273740] ? __pfx_intel_bts_interrupt+0x10/0x10
> [ 196.273742] ? intel_pmu_lbr_enable_all+0x25/0x150
> [ 196.273745] intel_pmu_handle_irq+0x388/0x700
> [ 196.273748] perf_event_nmi_handler+0xff/0x150
> [ 196.273751] nmi_handle.part.0+0xa8/0x2d0
> [ 196.273755] ? perf_output_begin+0x3e9/0xa10
> [ 196.273757] default_do_nmi+0x79/0x1a0
> [ 196.273760] fred_exc_nmi+0x40/0x90
> [ 196.273762] asm_fred_entrypoint_kernel+0x45/0x60
> [ 196.273765] RIP: 0010:perf_output_begin+0x3e9/0xa10
> [ 196.273768] Code: 54 24 1c 85 d2 0f 85 19 03 00 00 48 8b 44 24 18 48 c1 e8 03 42 0f b6 04 28 84 c0 74 08 3c 03 0f 8e 25 05 00 00 41 8b 44 24 18 <c1> e0 0c 48 98 48 83 e8 01 80 7c 24 2a 00 0f 85 f9 02 00 00 4c 29
> [ 196.273770] RSP: 0018:ffffc9001cf575e8 EFLAGS: 00000246
> [ 196.273774] RAX: 0000000000000080 RBX: ffff88c1a0f95028 RCX: 0000000000000004
> [ 196.273775] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88c08c8f9408
>
> [ 196.273777] RBP: 0000000000000028 R08: 0000000000000000 R09: ffffed18341f2a05
> [ 196.273778] R10: ffff88c1a0f9502f R11: ffff88c1a0dbe1b8 R12: ffff88c1a0f95000
> [ 196.273779] R13: dffffc0000000000 R14: 0000000000000000 R15: ffffc9001cf577e0
> [ 196.273782] </NMI>
>
> The issue is caused by below code in __grt_latency_data(). The code
> tries to access x86_hybrid_pmu structure which doesn't exist on
> non-hybrid platform like CWF.
>
> WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)
>
> So add is_hybrid() check before calling this WARN_ON_ONCE to fix the
> global-out-of-bounds access issue.
>
> Reported-by: Xudong Hao <xudong.hao@intel.com>
> Cc: stable@vger.kernel.org
> Fixes: 090262439f66 ("perf/x86/intel: Rename model-specific pebs_latency_data functions")
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> ---
> arch/x86/events/intel/ds.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
> index c0b7ac1c7594..d1ac1f1ceee9 100644
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -317,7 +317,7 @@ static u64 __grt_latency_data(struct perf_event *event, u64 status,
> {
> u64 val;
>
> - WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big);
> + WARN_ON_ONCE(is_hybrid() && hybrid_pmu(event->pmu)->pmu_type == hybrid_big);
BTW, this line has more than 80 characters.
Reviewed-by: Zide Chen <zide.chen@intel.com>
>
> dse &= PERF_PEBS_DATA_SOURCE_GRT_MASK;
> val = hybrid_var(event->pmu, pebs_data_source)[dse];
>
> base-commit: 16ed389227651330879e17bd83d43bd234006722
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] perf/x86/intel: Fix KASAN global-out-of-bounds warning
2025-10-23 17:45 ` Chen, Zide
@ 2025-10-24 0:37 ` Mi, Dapeng
0 siblings, 0 replies; 3+ messages in thread
From: Mi, Dapeng @ 2025-10-24 0:37 UTC (permalink / raw)
To: Chen, Zide, Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Kan Liang, Andi Kleen, Eranian Stephane
Cc: linux-kernel, linux-perf-users, Dapeng Mi, Xudong Hao, stable
On 10/24/2025 1:45 AM, Chen, Zide wrote:
>
> On 9/3/2025 6:24 PM, Dapeng Mi wrote:
>> When running "perf mem record" command on CWF, the below KASAN
>> global-out-of-bounds warning is seen.
>>
>> 196.273657] ==================================================================
>> [ 196.273662] BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0
>> [ 196.273669] Read of size 4 at addr ffffffffb721d000 by task dtlb/9850
>>
>> [ 196.273676] CPU: 126 UID: 0 PID: 9850 Comm: dtlb Kdump: loaded Not tainted 6.17.0-rc3-2025-08-29-intel-next-34160-g316938187eb0 #1 PREEMPT(none)
>> [ 196.273680] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P83.2507110208 07/11/2025
>> [ 196.273682] Call Trace:
>> [ 196.273683] <NMI>
>> [ 196.273684] dump_stack_lvl+0x55/0x70
>> [ 196.273689] print_address_description.constprop.0+0x2c/0x3d0
>> [ 196.273694] ? cmt_latency_data+0x176/0x1b0
>> [ 196.273696] print_report+0xb4/0x270
>> [ 196.273699] ? kasan_addr_to_slab+0xd/0xa0
>> [ 196.273702] kasan_report+0xb8/0xf0
>> [ 196.273705] ? cmt_latency_data+0x176/0x1b0
>> [ 196.273707] cmt_latency_data+0x176/0x1b0
>> [ 196.273710] setup_arch_pebs_sample_data+0xf49/0x2560
>> [ 196.273713] intel_pmu_drain_arch_pebs+0x577/0xb00
>> [ 196.273716] ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10
>> [ 196.273719] ? perf_output_begin+0x3e4/0xa10
>> [ 196.273724] ? intel_pmu_drain_bts_buffer+0xc2/0x6a0
>> [ 196.273727] ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10
>> [ 196.273730] handle_pmi_common+0x6c4/0xc80
>> [ 196.273734] ? __pfx_handle_pmi_common+0x10/0x10
>> [ 196.273738] ? intel_bts_interrupt+0xd3/0x4d0
>> [ 196.273740] ? __pfx_intel_bts_interrupt+0x10/0x10
>> [ 196.273742] ? intel_pmu_lbr_enable_all+0x25/0x150
>> [ 196.273745] intel_pmu_handle_irq+0x388/0x700
>> [ 196.273748] perf_event_nmi_handler+0xff/0x150
>> [ 196.273751] nmi_handle.part.0+0xa8/0x2d0
>> [ 196.273755] ? perf_output_begin+0x3e9/0xa10
>> [ 196.273757] default_do_nmi+0x79/0x1a0
>> [ 196.273760] fred_exc_nmi+0x40/0x90
>> [ 196.273762] asm_fred_entrypoint_kernel+0x45/0x60
>> [ 196.273765] RIP: 0010:perf_output_begin+0x3e9/0xa10
>> [ 196.273768] Code: 54 24 1c 85 d2 0f 85 19 03 00 00 48 8b 44 24 18 48 c1 e8 03 42 0f b6 04 28 84 c0 74 08 3c 03 0f 8e 25 05 00 00 41 8b 44 24 18 <c1> e0 0c 48 98 48 83 e8 01 80 7c 24 2a 00 0f 85 f9 02 00 00 4c 29
>> [ 196.273770] RSP: 0018:ffffc9001cf575e8 EFLAGS: 00000246
>> [ 196.273774] RAX: 0000000000000080 RBX: ffff88c1a0f95028 RCX: 0000000000000004
>> [ 196.273775] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88c08c8f9408
>>
>> [ 196.273777] RBP: 0000000000000028 R08: 0000000000000000 R09: ffffed18341f2a05
>> [ 196.273778] R10: ffff88c1a0f9502f R11: ffff88c1a0dbe1b8 R12: ffff88c1a0f95000
>> [ 196.273779] R13: dffffc0000000000 R14: 0000000000000000 R15: ffffc9001cf577e0
>> [ 196.273782] </NMI>
>>
>> The issue is caused by below code in __grt_latency_data(). The code
>> tries to access x86_hybrid_pmu structure which doesn't exist on
>> non-hybrid platform like CWF.
>>
>> WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)
>>
>> So add is_hybrid() check before calling this WARN_ON_ONCE to fix the
>> global-out-of-bounds access issue.
>>
>> Reported-by: Xudong Hao <xudong.hao@intel.com>
>> Cc: stable@vger.kernel.org
>> Fixes: 090262439f66 ("perf/x86/intel: Rename model-specific pebs_latency_data functions")
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> ---
>> arch/x86/events/intel/ds.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
>> index c0b7ac1c7594..d1ac1f1ceee9 100644
>> --- a/arch/x86/events/intel/ds.c
>> +++ b/arch/x86/events/intel/ds.c
>> @@ -317,7 +317,7 @@ static u64 __grt_latency_data(struct perf_event *event, u64 status,
>> {
>> u64 val;
>>
>> - WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big);
>> + WARN_ON_ONCE(is_hybrid() && hybrid_pmu(event->pmu)->pmu_type == hybrid_big);
> BTW, this line has more than 80 characters.
Ah, yes, I would fix it in v2. Thanks.
>
> Reviewed-by: Zide Chen <zide.chen@intel.com>
>
>
>>
>> dse &= PERF_PEBS_DATA_SOURCE_GRT_MASK;
>> val = hybrid_var(event->pmu, pebs_data_source)[dse];
>>
>> base-commit: 16ed389227651330879e17bd83d43bd234006722
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-10-24 0:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-04 1:24 [PATCH] perf/x86/intel: Fix KASAN global-out-of-bounds warning Dapeng Mi
2025-10-23 17:45 ` Chen, Zide
2025-10-24 0:37 ` Mi, Dapeng
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).