Message ID | 20230215115430.236046-2-yangjihong1@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp151950wrn; Wed, 15 Feb 2023 04:06:47 -0800 (PST) X-Google-Smtp-Source: AK7set9sVMLKOTegnwnds+dOlVYiHFFKCCSviHZ0mZav0SKLdQT6B8N1Uq2JbQ+8BDvG73IxXoOf X-Received: by 2002:a17:902:e741:b0:19a:7882:c1a9 with SMTP id p1-20020a170902e74100b0019a7882c1a9mr2363388plf.63.1676462807076; Wed, 15 Feb 2023 04:06:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676462807; cv=none; d=google.com; s=arc-20160816; b=YRdH+4ICAvEtG5hABkZp9mg7dfjRHVaUMVDH6Hi2rAo6zhyGdh6RydjcJ7+H1+ezqW UIzSu3CdGeA0u26r7TJPZC8NVFoPBfWIo6vNx3MOSnZCKM6YcfbP+bgLQTodQa2MaCGu PDpxvAhrWToDa5LXfYrVN/Z050soZ83F10LDopRfdLcZ1UG0HU+9/WpW/OEDcXaHfzgI pUmQJ6aC9HxaYyCvjOSfCkVDROYyRX0/TQ6gBA924h5YHc0nyvhrWMzrYc2g7qGzYyT1 6wrnt4oN2QwZVs55ptHQ/FKWQS0hIoOKJJx4uR0vcVcbVYeGaXZ/xOo2U+26UyH7HeVQ yTVw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=syds4WrikRA3CGkmc0bIAt17fnnYlCT4rerthLe8hHc=; b=FJ/4hDCA0w0XaM/cYyfzIleUf/RIl+1JmhPiEE0jolIUk39D5Vpz5swca7i9YCpF8z eN58xPUvspyYF6aY2WPI42Xb0InfcoTeNSXkIF+GTQLbi+vewDZWr8FO/PgrYx5R7Ljz nI/2ZNgdDRqvea0f/+3bObb8DtYtUkyxr0dirBwtY2x94sJJk8+XRno51A8LXvysmyl/ 01BR5qMMwYEGE8u+5OaAm2d6ajvIKgUwPZQpVSx1fku3twNhC1o6BrKOGwQZTjvcLr65 cTiyUyf5buK4rD+kDmmcn6nOMxuFRLOzpv8Jnp3SsT2hGF6uxejJiZsmsMaHa/5W43FS i+iQ== 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 bb10-20020a170902bc8a00b001960e5dcb99si14807355plb.223.2023.02.15.04.06.34; Wed, 15 Feb 2023 04:06:47 -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 S233877AbjBOL4y (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Wed, 15 Feb 2023 06:56:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232544AbjBOL4q (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 15 Feb 2023 06:56:46 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D88628842; Wed, 15 Feb 2023 03:56:44 -0800 (PST) Received: from kwepemm600003.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4PGxPD6f26zrRvN; Wed, 15 Feb 2023 19:56:16 +0800 (CST) Received: from ubuntu1804.huawei.com (10.67.174.61) by kwepemm600003.china.huawei.com (7.193.23.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Wed, 15 Feb 2023 19:56:40 +0800 From: Yang Jihong <yangjihong1@huawei.com> To: <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>, <dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>, <naveen.n.rao@linux.ibm.com>, <anil.s.keshavamurthy@intel.com>, <davem@davemloft.net>, <mhiramat@kernel.org>, <ast@kernel.org>, <peterz@infradead.org>, <linux-kernel@vger.kernel.org>, <linux-trace-kernel@vger.kernel.org> CC: <yangjihong1@huawei.com> Subject: [PATCH 1/3] kprobes: Fixed probe nodes not correctly removed when forcibly unoptimized Date: Wed, 15 Feb 2023 19:54:28 +0800 Message-ID: <20230215115430.236046-2-yangjihong1@huawei.com> X-Mailer: git-send-email 2.30.GIT In-Reply-To: <20230215115430.236046-1-yangjihong1@huawei.com> References: <20230215115430.236046-1-yangjihong1@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.174.61] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600003.china.huawei.com (7.193.23.202) 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?1757898664375994835?= X-GMAIL-MSGID: =?utf-8?q?1757898664375994835?= |
Series |
kprobes: Fix issues related to optkprobe
|
|
Commit Message
Yang Jihong
Feb. 15, 2023, 11:54 a.m. UTC
When unoptimize_kprobe forcibly unoptimize the kprobe, simply queue it in
the freeing_list, and do_free_cleaned_kprobes directly reclaims the kprobe
if unoptimizing_list is empty (see do_unoptimize_kprobes), which may cause
WARN or UAF problems.
The specific scenarios are as follows:
Thread1
arm_kprobe(p)
mutex_lock(&kprobe_mutex)
__arm_kprobe(kp)
p = get_optimized_kprobe(p->addr)
if (unlikely(_p))
unoptimize_kprobe(_p, true) // now _p is queued in freeing_list
mutex_unlock(&kprobe_mutex)
Thread2
kprobe_optimizer
mutex_lock(&kprobe_mutex)
do_unoptimize_kprobes
if (list_empty(&unoptimizing_list))
return; // here directly returned and does not process freeing_list.
...
do_free_cleaned_kprobes
foreach op in freeing_list:
WARN_ON_ONCE(!kprobe_unused(&op->kp)) // WANR will be triggered here.
free_aggr_kprobe((&op->kp) // Delete op->kp directly, if access hash
// list later, UAF problem will be triggered.
mutex_unlock(&kprobe_mutex)
The freeing_list needs to be processed in do_unoptimize_kprobes regardless
of whether unoptimizing_list is empty.
Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
---
kernel/kprobes.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Comments
Hi Yang, Thanks for reporting, but maybe this is a part of following fix. https://lore.kernel.org/all/167448024501.3253718.13037333683110512967.stgit@devnote3/ Can you confirm that fixes the same issue? Thank you, On Wed, 15 Feb 2023 19:54:28 +0800 Yang Jihong <yangjihong1@huawei.com> wrote: > When unoptimize_kprobe forcibly unoptimize the kprobe, simply queue it in > the freeing_list, and do_free_cleaned_kprobes directly reclaims the kprobe > if unoptimizing_list is empty (see do_unoptimize_kprobes), which may cause > WARN or UAF problems. > > The specific scenarios are as follows: > > Thread1 > arm_kprobe(p) > mutex_lock(&kprobe_mutex) > __arm_kprobe(kp) > p = get_optimized_kprobe(p->addr) > if (unlikely(_p)) > unoptimize_kprobe(_p, true) // now _p is queued in freeing_list > mutex_unlock(&kprobe_mutex) > > Thread2 > kprobe_optimizer > mutex_lock(&kprobe_mutex) > do_unoptimize_kprobes > if (list_empty(&unoptimizing_list)) > return; // here directly returned and does not process freeing_list. > ... > do_free_cleaned_kprobes > foreach op in freeing_list: > WARN_ON_ONCE(!kprobe_unused(&op->kp)) // WANR will be triggered here. > free_aggr_kprobe((&op->kp) // Delete op->kp directly, if access hash > // list later, UAF problem will be triggered. > mutex_unlock(&kprobe_mutex) > > The freeing_list needs to be processed in do_unoptimize_kprobes regardless > of whether unoptimizing_list is empty. > > Signed-off-by: Yang Jihong <yangjihong1@huawei.com> > --- > kernel/kprobes.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > index 1c18ecf9f98b..0730e595f4c1 100644 > --- a/kernel/kprobes.c > +++ b/kernel/kprobes.c > @@ -556,10 +556,9 @@ static void do_unoptimize_kprobes(void) > lockdep_assert_cpus_held(); > > /* Unoptimization must be done anytime */ > - if (list_empty(&unoptimizing_list)) > - return; > + if (!list_empty(&unoptimizing_list)) > + arch_unoptimize_kprobes(&unoptimizing_list, &freeing_list); > > - arch_unoptimize_kprobes(&unoptimizing_list, &freeing_list); > /* Loop on 'freeing_list' for disarming */ > list_for_each_entry_safe(op, tmp, &freeing_list, list) { > /* Switching from detour code to origin */ > -- > 2.30.GIT >
Hello Masami, On 2023/2/15 22:55, Masami Hiramatsu (Google) wrote: > Hi Yang, > > Thanks for reporting, but maybe this is a part of following fix. > > https://lore.kernel.org/all/167448024501.3253718.13037333683110512967.stgit@devnote3/ > > Can you confirm that fixes the same issue? Yes, I've tested and confirmed that the patch you mentioned above fixes the same issue. Will remove it in next version. Thanks Yang.
diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 1c18ecf9f98b..0730e595f4c1 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -556,10 +556,9 @@ static void do_unoptimize_kprobes(void) lockdep_assert_cpus_held(); /* Unoptimization must be done anytime */ - if (list_empty(&unoptimizing_list)) - return; + if (!list_empty(&unoptimizing_list)) + arch_unoptimize_kprobes(&unoptimizing_list, &freeing_list); - arch_unoptimize_kprobes(&unoptimizing_list, &freeing_list); /* Loop on 'freeing_list' for disarming */ list_for_each_entry_safe(op, tmp, &freeing_list, list) { /* Switching from detour code to origin */