Message ID | 20221108083124.27218-3-shangxiaojing@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2564989wru; Tue, 8 Nov 2022 00:33:42 -0800 (PST) X-Google-Smtp-Source: AMsMyM4lseNFlQOl42lFkozWQxlD1X7znoqdyTPxBGGXmAk2bBCSdQ2PVzceXSdCXXBIC2vJ47Bo X-Received: by 2002:a17:90b:1950:b0:212:de19:b3ce with SMTP id nk16-20020a17090b195000b00212de19b3cemr55032116pjb.16.1667896422337; Tue, 08 Nov 2022 00:33:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667896422; cv=none; d=google.com; s=arc-20160816; b=G+9e2gcSVg7m4kBWwvkDNZF3RqgNag5pwYQruwunIX3DRMxXJ8VDftN2Q3O7FJtMx1 S4rLrB/umu3PEuFF8c+A2z9r7vtIYTc4t7meyOXjf+OLtz3v7pnFk0+k31L7FIOA9mBb W1R1XPRlntTQQAscbViDpjZY7G0nk8FIgfmpVyjyw9bkgBAyoZUHtjdjikbWYN1VF51d 7u/0XlNdGiOxsRWLeQalxaVsitFVdTrinN8Xh01YSmn1nOfTnf0pFe9dzsy+BHRBPUhO FpRwz7rX6UC5qH7VNdDC/1ChhGfoZ+xuDJyRcEphPcZs/gmyroIihp35zkPLlF9VGE0b PJjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=m461xGNiiJmtd0QufNqBD/SlezHAKraaKYL39uL6uas=; b=IhMG12TQUkZRsNLUEy3uRVtaJfgXAIxnc+QD128dMTJJhQ1zB5NFwkKHD1iSVQHjMp CK0wUe6LwMU1WIrTRsY6Ju7ihw+00SHcMxjRJI83adEUfaJHYkjvlblsR39OWycXZmBp QE93sJg1MFGK7jjYzalZ0mXHSSUPUJBe42iK8G5+QNIByP4IdmG22JiAURNaJPnKvois Q81fsW5B03+EVc7BnQwkZdtBIAN76i+lw9Lz2EU3YgMd80AydNdZDTW5Ns9Ie7jziqqk owExdot3RynDpjikfKFyuCcbIh2MVtE4TmSHhXASYNDDVow5a9/s7PDs8rUmN8Zq/IfO 1Qqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v18-20020a17090ac91200b0020a755f2b83si14878217pjt.100.2022.11.08.00.33.29; Tue, 08 Nov 2022 00:33:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233563AbiKHIcz (ORCPT <rfc822;hjfbswb@gmail.com> + 99 others); Tue, 8 Nov 2022 03:32:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233506AbiKHIcr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 8 Nov 2022 03:32:47 -0500 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0858327B39 for <linux-kernel@vger.kernel.org>; Tue, 8 Nov 2022 00:32:46 -0800 (PST) Received: from kwepemi500016.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4N61Ys1XZmz15MMJ; Tue, 8 Nov 2022 16:32:33 +0800 (CST) Received: from huawei.com (10.175.100.227) by kwepemi500016.china.huawei.com (7.221.188.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 8 Nov 2022 16:32:43 +0800 From: Shang XiaoJing <shangxiaojing@huawei.com> To: <rostedt@goodmis.org>, <mhiramat@kernel.org>, <zanussi@kernel.org>, <fengguang.wu@intel.com>, <linux-kernel@vger.kernel.org> CC: <shangxiaojing@huawei.com> Subject: [PATCH 2/2] tracing: Fix wild-memory-access in register_synth_event() Date: Tue, 8 Nov 2022 16:31:23 +0800 Message-ID: <20221108083124.27218-3-shangxiaojing@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20221108083124.27218-1-shangxiaojing@huawei.com> References: <20221108083124.27218-1-shangxiaojing@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.100.227] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemi500016.china.huawei.com (7.221.188.220) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748916158758467111?= X-GMAIL-MSGID: =?utf-8?q?1748916158758467111?= |
Series |
tracing: Fix some bug about synth
|
|
Commit Message
Shang XiaoJing
Nov. 8, 2022, 8:31 a.m. UTC
In register_synth_event(), if set_synth_event_print_fmt() failed, then
both trace_remove_event_call() and unregister_trace_event() will be
called. If call->event.funcs is not NULL, then the trace_event_call will
call __unregister_trace_event() twice. As the result, the second
__unregister_trace_event() will causes the wild-memory-access.
register_synth_event
set_synth_event_print_fmt failed
trace_remove_event_call
event_remove
if call->event.funcs then
__unregister_trace_event (first call)
unregister_trace_event
__unregister_trace_event (second call)
Fix the bug by avoiding to call the second __unregister_trace_event() by
checking if the first one is called.
general protection fault, probably for non-canonical address
0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI
KASAN: maybe wild-memory-access in range
[0xdead000000000120-0xdead000000000127]
CPU: 0 PID: 3807 Comm: modprobe Not tainted
6.1.0-rc1-00186-g76f33a7eedb4 #299
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:unregister_trace_event+0x6e/0x280
Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48
b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02
00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b
RSP: 0018:ffff88810413f370 EFLAGS: 00010a06
RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000
RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20
RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481
R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122
R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028
FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__create_synth_event+0x1e37/0x1eb0
create_or_delete_synth_event+0x110/0x250
synth_event_run_command+0x2f/0x110
test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test]
synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test]
do_one_initcall+0xdb/0x480
do_init_module+0x1cf/0x680
load_module+0x6a50/0x70a0
__do_sys_finit_module+0x12f/0x1c0
do_syscall_64+0x3f/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fixes: 4b147936fa50 ("tracing: Add support for 'synthetic' events")
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Cc: stable@vger.kernel.org
---
kernel/trace/trace_events_synth.c | 2 ++
1 file changed, 2 insertions(+)
Comments
Hi Shang, On Tue, 2022-11-08 at 16:31 +0800, Shang XiaoJing wrote: > In register_synth_event(), if set_synth_event_print_fmt() failed, then > both trace_remove_event_call() and unregister_trace_event() will be > called. If call->event.funcs is not NULL, then the trace_event_call will > call __unregister_trace_event() twice. As the result, the second > __unregister_trace_event() will causes the wild-memory-access. > > register_synth_event > set_synth_event_print_fmt failed > trace_remove_event_call > event_remove > if call->event.funcs then > __unregister_trace_event (first call) > unregister_trace_event > __unregister_trace_event (second call) > > Fix the bug by avoiding to call the second __unregister_trace_event() by > checking if the first one is called. > > general protection fault, probably for non-canonical address > 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI > KASAN: maybe wild-memory-access in range > [0xdead000000000120-0xdead000000000127] > CPU: 0 PID: 3807 Comm: modprobe Not tainted > 6.1.0-rc1-00186-g76f33a7eedb4 #299 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 > RIP: 0010:unregister_trace_event+0x6e/0x280 > Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 > b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 > 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b > RSP: 0018:ffff88810413f370 EFLAGS: 00010a06 > RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 > RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 > RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481 > R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 > R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 > FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) > knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > __create_synth_event+0x1e37/0x1eb0 > create_or_delete_synth_event+0x110/0x250 > synth_event_run_command+0x2f/0x110 > test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] > synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] > do_one_initcall+0xdb/0x480 > do_init_module+0x1cf/0x680 > load_module+0x6a50/0x70a0 > __do_sys_finit_module+0x12f/0x1c0 > do_syscall_64+0x3f/0x90 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > Fixes: 4b147936fa50 ("tracing: Add support for 'synthetic' events") > Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> > Cc: stable@vger.kernel.org > --- > kernel/trace/trace_events_synth.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c > index e310052dc83c..a51280a153e3 100644 > --- a/kernel/trace/trace_events_synth.c > +++ b/kernel/trace/trace_events_synth.c > @@ -830,6 +830,8 @@ static int register_synth_event(struct synth_event *event) > ret = set_synth_event_print_fmt(call); > if (ret < 0) { > trace_remove_event_call(call); > + if (call->event.funcs) > + return ret; > goto err; > } > out: Good catch, thanks for finding this bug! It looks like call->event.funcs will always be true here since it's set to &synth_event_funcs above. So it seems like you could just call trace_remove_event_call() and fall through for this (ret < 0) case? If so, it might be good to put a comment there noting that trace_remove_event_call() will call unregister_trace_event(), so it's ok to just return. Thanks, Tom
On 2022/11/13 5:24, Tom Zanussi wrote: > Hi Shang, > > On Tue, 2022-11-08 at 16:31 +0800, Shang XiaoJing wrote: >> In register_synth_event(), if set_synth_event_print_fmt() failed, then >> both trace_remove_event_call() and unregister_trace_event() will be >> called. If call->event.funcs is not NULL, then the trace_event_call will >> call __unregister_trace_event() twice. As the result, the second >> __unregister_trace_event() will causes the wild-memory-access. >> >> register_synth_event >> set_synth_event_print_fmt failed >> trace_remove_event_call >> event_remove >> if call->event.funcs then >> __unregister_trace_event (first call) >> unregister_trace_event >> __unregister_trace_event (second call) >> >> Fix the bug by avoiding to call the second __unregister_trace_event() by >> checking if the first one is called. >> >> general protection fault, probably for non-canonical address >> 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI >> KASAN: maybe wild-memory-access in range >> [0xdead000000000120-0xdead000000000127] >> CPU: 0 PID: 3807 Comm: modprobe Not tainted >> 6.1.0-rc1-00186-g76f33a7eedb4 #299 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 >> RIP: 0010:unregister_trace_event+0x6e/0x280 >> Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 >> b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 >> 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b >> RSP: 0018:ffff88810413f370 EFLAGS: 00010a06 >> RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 >> RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 >> RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481 >> R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 >> R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 >> FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) >> knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 >> Call Trace: >> <TASK> >> __create_synth_event+0x1e37/0x1eb0 >> create_or_delete_synth_event+0x110/0x250 >> synth_event_run_command+0x2f/0x110 >> test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] >> synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] >> do_one_initcall+0xdb/0x480 >> do_init_module+0x1cf/0x680 >> load_module+0x6a50/0x70a0 >> __do_sys_finit_module+0x12f/0x1c0 >> do_syscall_64+0x3f/0x90 >> entry_SYSCALL_64_after_hwframe+0x63/0xcd >> >> Fixes: 4b147936fa50 ("tracing: Add support for 'synthetic' events") >> Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> >> Cc: stable@vger.kernel.org >> --- >> kernel/trace/trace_events_synth.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c >> index e310052dc83c..a51280a153e3 100644 >> --- a/kernel/trace/trace_events_synth.c >> +++ b/kernel/trace/trace_events_synth.c >> @@ -830,6 +830,8 @@ static int register_synth_event(struct synth_event *event) >> ret = set_synth_event_print_fmt(call); >> if (ret < 0) { >> trace_remove_event_call(call); >> + if (call->event.funcs) >> + return ret; >> goto err; >> } >> out: > > Good catch, thanks for finding this bug! > > It looks like call->event.funcs will always be true here since it's set > to &synth_event_funcs above. > > So it seems like you could just call trace_remove_event_call() and fall > through for this (ret < 0) case? If so, it might be good to put a > comment there noting that trace_remove_event_call() will call > unregister_trace_event(), so it's ok to just return. > Ok, will fix in v2. Thanks,
diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c index e310052dc83c..a51280a153e3 100644 --- a/kernel/trace/trace_events_synth.c +++ b/kernel/trace/trace_events_synth.c @@ -830,6 +830,8 @@ static int register_synth_event(struct synth_event *event) ret = set_synth_event_print_fmt(call); if (ret < 0) { trace_remove_event_call(call); + if (call->event.funcs) + return ret; goto err; } out: