Message ID | 20230615115236.3476617-1-jolsa@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp609808vqr; Thu, 15 Jun 2023 05:52:57 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4NQRPeHgVdfP3JFyPdMQaz9YNQ5t00RYLTqKtJMc1WHhLIasVuDREC0d4OwMn33Q1qErL3 X-Received: by 2002:a17:902:7616:b0:1b1:7336:2634 with SMTP id k22-20020a170902761600b001b173362634mr13064843pll.57.1686833577555; Thu, 15 Jun 2023 05:52:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686833577; cv=none; d=google.com; s=arc-20160816; b=j6DUgzbl4DIYn61vw68e6FEnEHxIi+N6BUK3HZfp/Ye4GyW/60QTyi8cEZhkVUgaLw FpXyj9WTDcMyG6LPYo3SWnL1F9+sbfy0NH0172ODQoRI/VsaUMoj9Eh6CQxpjLC5ow23 CiSP1JfGnQfkQGuPxr3oWi5V7P2cauDA9vNjuncquixq8WqNlpxkXN1z144EqKoN1GDj Fb2oFfyCoRMaFhD+qoGzDdozPQhFgqQqqmnilaDFGFVM2B4o22pwrMG7rvKh5pDZZSi8 WmsLOzQLNMjgoViC1ZOw2D7j1c072gksZeSnnHbFFhlWic9zs9c9lfmRTCgPUaL8KfPb kiYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=bYABnbzJPe8O6Mh/pen56bQx0XBT1rpkUkDpduteH3w=; b=L6d85f6absvX0QqD/qpueyQ5NHgdy7fWCRjgxgJQavkrtOTN/aGxVEONPb19Os9PgJ L440rkGUDTPA3g9EXBonxUg3eDVxxQ08FLrXnoAGPKHogzNHZFDxrPuh50axEmMS82VN EldvkNvq/q0QImRuoGofyxAlrfZvtQbCC8BOoaq1AUGyS0WvlmNxYhLnYOFoGZ8ZeMqy HtW4NvzUzypPJxeZXMGjkmf8kVAx5/0J1whvq11vZtGrY9YZtB5iU01UOXDh/yLh/6TH 9Y8uxt9Ji3aud1RhY/iGKDbFsPeNiPztaV40eVq7/IXqYLlrDrqp424b0ZQyDiIhZn0Q WFyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ETYkAhwt; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f5-20020a170902ce8500b001a6e98a5f21si7910693plg.586.2023.06.15.05.52.44; Thu, 15 Jun 2023 05:52:57 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ETYkAhwt; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344649AbjFOL7G (ORCPT <rfc822;n2h9z4@gmail.com> + 99 others); Thu, 15 Jun 2023 07:59:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239068AbjFOL6t (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 15 Jun 2023 07:58:49 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA12E5FC0; Thu, 15 Jun 2023 04:53:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3D9A4637B1; Thu, 15 Jun 2023 11:52:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F06B1C433C8; Thu, 15 Jun 2023 11:52:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686829960; bh=vzXaLtl6SzbvAGUpSSunsAgBa5POCxudf8Ga0otXJQU=; h=From:To:Cc:Subject:Date:From; b=ETYkAhwtp5kNnRtpjzuT4+P3vKvOR2SXhqd4Q8qIpLEGQl6dYfiqvReb117moKwM0 LdRSt8WIYArfD9xxw9VDPZkTSWuHYapMzGO0mAQIHYlfaZalEYEUIxzcXQNxfgplip HFSkXpe4WVm8vK1ciYLuagzQS77bEkvoRMS9V0DxIqX/IpuS3JOBRhOuDHK1QlOQJh ZuVKK4rULuoGZdXfT5urJ5l1fOfaOuLe7P14w9PSeSu6nEAocRDhXIdQXNFJTwFShi /wM/YDUZ9tDa5U3Zf3y+3cTlwxPE9hKOABGrBM2pcfjZYmcgPaBrZrQlZmxvcaKYkJ pRsGyu2GFtomA== From: Jiri Olsa <jolsa@kernel.org> To: Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu <mhiramat@kernel.org>, Mark Rutland <mark.rutland@arm.com> Cc: lkml <linux-kernel@vger.kernel.org>, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org Subject: [PATCH] fprobe: Release rethook after the ftrace_ops is unregistered Date: Thu, 15 Jun 2023 13:52:36 +0200 Message-Id: <20230615115236.3476617-1-jolsa@kernel.org> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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?1768773205701132534?= X-GMAIL-MSGID: =?utf-8?q?1768773205701132534?= |
Series |
fprobe: Release rethook after the ftrace_ops is unregistered
|
|
Commit Message
Jiri Olsa
June 15, 2023, 11:52 a.m. UTC
While running bpf selftests it's possible to get following fault: general protection fault, probably for non-canonical address \ 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI ... Call Trace: <TASK> fprobe_handler+0xc1/0x270 ? __pfx_bpf_testmod_init+0x10/0x10 ? __pfx_bpf_testmod_init+0x10/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_testmod_init+0x22/0x80 ? do_one_initcall+0x63/0x2e0 ? rcu_is_watching+0xd/0x40 ? kmalloc_trace+0xaf/0xc0 ? do_init_module+0x60/0x250 ? __do_sys_finit_module+0xac/0x120 ? do_syscall_64+0x37/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc </TASK> In unregister_fprobe function we can't release fp->rethook while it's possible there are some of its users still running on another cpu. Moving rethook_free call after fp->ops is unregistered with unregister_ftrace_function call. Fixes: 5b0ab78998e3 ("fprobe: Add exit_handler support") Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> --- kernel/trace/fprobe.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
Comments
Masami, Want to take this via your probes/urgent branch and send it off to Linus? -- Steve On Thu, 15 Jun 2023 13:52:36 +0200 Jiri Olsa <jolsa@kernel.org> wrote: > While running bpf selftests it's possible to get following fault: > > general protection fault, probably for non-canonical address \ > 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI > ... > Call Trace: > <TASK> > fprobe_handler+0xc1/0x270 > ? __pfx_bpf_testmod_init+0x10/0x10 > ? __pfx_bpf_testmod_init+0x10/0x10 > ? bpf_fentry_test1+0x5/0x10 > ? bpf_fentry_test1+0x5/0x10 > ? bpf_testmod_init+0x22/0x80 > ? do_one_initcall+0x63/0x2e0 > ? rcu_is_watching+0xd/0x40 > ? kmalloc_trace+0xaf/0xc0 > ? do_init_module+0x60/0x250 > ? __do_sys_finit_module+0xac/0x120 > ? do_syscall_64+0x37/0x90 > ? entry_SYSCALL_64_after_hwframe+0x72/0xdc > </TASK> > > In unregister_fprobe function we can't release fp->rethook while it's > possible there are some of its users still running on another cpu. > > Moving rethook_free call after fp->ops is unregistered with > unregister_ftrace_function call. > > Fixes: 5b0ab78998e3 ("fprobe: Add exit_handler support") > Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> > Signed-off-by: Jiri Olsa <jolsa@kernel.org> > --- > kernel/trace/fprobe.c | 12 +++--------- > 1 file changed, 3 insertions(+), 9 deletions(-) > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > index 18d36842faf5..0121e8c0d54e 100644 > --- a/kernel/trace/fprobe.c > +++ b/kernel/trace/fprobe.c > @@ -364,19 +364,13 @@ int unregister_fprobe(struct fprobe *fp) > fp->ops.saved_func != fprobe_kprobe_handler)) > return -EINVAL; > > - /* > - * rethook_free() starts disabling the rethook, but the rethook handlers > - * may be running on other processors at this point. To make sure that all > - * current running handlers are finished, call unregister_ftrace_function() > - * after this. > - */ > - if (fp->rethook) > - rethook_free(fp->rethook); > - > ret = unregister_ftrace_function(&fp->ops); > if (ret < 0) > return ret; > > + if (fp->rethook) > + rethook_free(fp->rethook); > + > ftrace_free_filter(&fp->ops); > > return ret;
On Thu, Jun 15, 2023 at 08:59:20AM -0400, Steven Rostedt wrote: > > Masami, > > Want to take this via your probes/urgent branch and send it off to Linus? hi, did this one make it into some tree? thanks, jirka > > -- Steve > > > On Thu, 15 Jun 2023 13:52:36 +0200 > Jiri Olsa <jolsa@kernel.org> wrote: > > > While running bpf selftests it's possible to get following fault: > > > > general protection fault, probably for non-canonical address \ > > 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI > > ... > > Call Trace: > > <TASK> > > fprobe_handler+0xc1/0x270 > > ? __pfx_bpf_testmod_init+0x10/0x10 > > ? __pfx_bpf_testmod_init+0x10/0x10 > > ? bpf_fentry_test1+0x5/0x10 > > ? bpf_fentry_test1+0x5/0x10 > > ? bpf_testmod_init+0x22/0x80 > > ? do_one_initcall+0x63/0x2e0 > > ? rcu_is_watching+0xd/0x40 > > ? kmalloc_trace+0xaf/0xc0 > > ? do_init_module+0x60/0x250 > > ? __do_sys_finit_module+0xac/0x120 > > ? do_syscall_64+0x37/0x90 > > ? entry_SYSCALL_64_after_hwframe+0x72/0xdc > > </TASK> > > > > In unregister_fprobe function we can't release fp->rethook while it's > > possible there are some of its users still running on another cpu. > > > > Moving rethook_free call after fp->ops is unregistered with > > unregister_ftrace_function call. > > > > Fixes: 5b0ab78998e3 ("fprobe: Add exit_handler support") > > Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org> > > --- > > kernel/trace/fprobe.c | 12 +++--------- > > 1 file changed, 3 insertions(+), 9 deletions(-) > > > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > > index 18d36842faf5..0121e8c0d54e 100644 > > --- a/kernel/trace/fprobe.c > > +++ b/kernel/trace/fprobe.c > > @@ -364,19 +364,13 @@ int unregister_fprobe(struct fprobe *fp) > > fp->ops.saved_func != fprobe_kprobe_handler)) > > return -EINVAL; > > > > - /* > > - * rethook_free() starts disabling the rethook, but the rethook handlers > > - * may be running on other processors at this point. To make sure that all > > - * current running handlers are finished, call unregister_ftrace_function() > > - * after this. > > - */ > > - if (fp->rethook) > > - rethook_free(fp->rethook); > > - > > ret = unregister_ftrace_function(&fp->ops); > > if (ret < 0) > > return ret; > > > > + if (fp->rethook) > > + rethook_free(fp->rethook); > > + > > ftrace_free_filter(&fp->ops); > > > > return ret; >
Hi Jiri, On Thu, 15 Jun 2023 13:52:36 +0200 Jiri Olsa <jolsa@kernel.org> wrote: > While running bpf selftests it's possible to get following fault: > > general protection fault, probably for non-canonical address \ > 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI > ... > Call Trace: > <TASK> > fprobe_handler+0xc1/0x270 > ? __pfx_bpf_testmod_init+0x10/0x10 > ? __pfx_bpf_testmod_init+0x10/0x10 > ? bpf_fentry_test1+0x5/0x10 > ? bpf_fentry_test1+0x5/0x10 > ? bpf_testmod_init+0x22/0x80 > ? do_one_initcall+0x63/0x2e0 > ? rcu_is_watching+0xd/0x40 > ? kmalloc_trace+0xaf/0xc0 > ? do_init_module+0x60/0x250 > ? __do_sys_finit_module+0xac/0x120 > ? do_syscall_64+0x37/0x90 > ? entry_SYSCALL_64_after_hwframe+0x72/0xdc > </TASK> > > In unregister_fprobe function we can't release fp->rethook while it's > possible there are some of its users still running on another cpu. Ah, OK. rethook_free() invoked call_rcu(rethook_free_rcu) to free the rethook, and it is possible rethook_free_rcu() is called before disabling all fprobe, then `rethook_try_get(fp->rethook)` will access fp->rethook which has been freed. > > Moving rethook_free call after fp->ops is unregistered with > unregister_ftrace_function call. > > Fixes: 5b0ab78998e3 ("fprobe: Add exit_handler support") > Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> > Signed-off-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Thank you! > --- > kernel/trace/fprobe.c | 12 +++--------- > 1 file changed, 3 insertions(+), 9 deletions(-) > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > index 18d36842faf5..0121e8c0d54e 100644 > --- a/kernel/trace/fprobe.c > +++ b/kernel/trace/fprobe.c > @@ -364,19 +364,13 @@ int unregister_fprobe(struct fprobe *fp) > fp->ops.saved_func != fprobe_kprobe_handler)) > return -EINVAL; > > - /* > - * rethook_free() starts disabling the rethook, but the rethook handlers > - * may be running on other processors at this point. To make sure that all > - * current running handlers are finished, call unregister_ftrace_function() > - * after this. > - */ > - if (fp->rethook) > - rethook_free(fp->rethook); > - > ret = unregister_ftrace_function(&fp->ops); > if (ret < 0) > return ret; > > + if (fp->rethook) > + rethook_free(fp->rethook); > + > ftrace_free_filter(&fp->ops); > > return ret; > -- > 2.40.1 >
On Tue, 27 Jun 2023 23:33:06 +0900 Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote: > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > > index 18d36842faf5..0121e8c0d54e 100644 > > --- a/kernel/trace/fprobe.c > > +++ b/kernel/trace/fprobe.c > > @@ -364,19 +364,13 @@ int unregister_fprobe(struct fprobe *fp) > > fp->ops.saved_func != fprobe_kprobe_handler)) > > return -EINVAL; > > > > - /* > > - * rethook_free() starts disabling the rethook, but the rethook handlers > > - * may be running on other processors at this point. To make sure that all > > - * current running handlers are finished, call unregister_ftrace_function() > > - * after this. > > - */ Oh, wait, here is an important comment. If a rethook handler is still running (because it hooks target function exit), returning from unregister_fprobe() right after rethook_free() may cause another issue. rethook_free() clears 'rh->handler', so after calling rethook_free(), we can ensure no NEW rethook handler (means fprobe_exit_handler()) is called. However, it doesn't mean there is no current running fprobe_exit_handler(). Thus if unregister_fprobe() caller releases the 'fp' right after returning from unregister_fprobe(), current running fprobe_exit_handler() can access 'fp' (use-after-free). Thus we need to add below code with this patch; /* * The rethook handlers may be running on other processors at this point. * To make sure that all current running handlers are finished, disable * rethook by clearing handler and call unregister_ftrace_function() * to ensure all running rethook handlers exit. And call rethook_free(). */ if (fp->rethook) WRITE_ONCE(fp->rethook->handler, NULL); > > - if (fp->rethook) > > - rethook_free(fp->rethook); > > - > > ret = unregister_ftrace_function(&fp->ops); > > if (ret < 0) > > return ret; > > > > + if (fp->rethook) > > + rethook_free(fp->rethook); > > + > > ftrace_free_filter(&fp->ops); > > > > return ret; Thank you, > > -- > > 2.40.1 > > > > > -- > Masami Hiramatsu (Google) <mhiramat@kernel.org>
diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c index 18d36842faf5..0121e8c0d54e 100644 --- a/kernel/trace/fprobe.c +++ b/kernel/trace/fprobe.c @@ -364,19 +364,13 @@ int unregister_fprobe(struct fprobe *fp) fp->ops.saved_func != fprobe_kprobe_handler)) return -EINVAL; - /* - * rethook_free() starts disabling the rethook, but the rethook handlers - * may be running on other processors at this point. To make sure that all - * current running handlers are finished, call unregister_ftrace_function() - * after this. - */ - if (fp->rethook) - rethook_free(fp->rethook); - ret = unregister_ftrace_function(&fp->ops); if (ret < 0) return ret; + if (fp->rethook) + rethook_free(fp->rethook); + ftrace_free_filter(&fp->ops); return ret;