[net,v2] 9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition
Message ID | 20230313090002.3308025-1-zyytlz.wz@163.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1084083wrd; Mon, 13 Mar 2023 02:34:36 -0700 (PDT) X-Google-Smtp-Source: AK7set/pEVf0yTOVku1SgVdEfAA6pU7oixFT7XUPH23s6BBYQbp6Jr8J4KO6smnZrM0z94dA2Vzk X-Received: by 2002:a17:902:e801:b0:19a:b4a9:9df7 with SMTP id u1-20020a170902e80100b0019ab4a99df7mr40665122plg.53.1678700076016; Mon, 13 Mar 2023 02:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678700076; cv=none; d=google.com; s=arc-20160816; b=oaRaK5SsYGcznrSYvkESjSj5HZHawToCczBnoCgk8GKKcHcsbLuaqhyDZMLmKCb8uF OQy8OEtjHkpSEpkl1piDrEOY3fkYXqfBa+VSTLlBEBa7A9yIbmaG5PL5KHRFwwENP4YZ W7ClPcJanx+DVY0ASfWGq700B3kMkVkrkw+i6skCpxIRr5s/RJIBGxtO+4JSRka4SFd/ x8j6pP/lmhnTRxA7Ho482sbDmuc08QLR7WCXeb7Y3oYaGiT1SxMTX7sBzKn9cELdVSfK VxCm55mbvFrQSnH26rrktmakWBlZ6ZkU5NvD6Irfpg0MUsLeWM56ozWwpl+qEMP7Cbvg rz5Q== 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=Gp4+C4gCMjSOFnYU898NA74fjHaBuOlyPKxcR6f/MrM=; b=vzMm5suHA8Zu9Xq5Og70O+7wDN6OFwswCBYWTeVGwgrD+PjJW/XZhy+r5XEFh5dAhd W7g0yK27DTK2sumnEGm01+/F3SzcjUQ+aBR89gIjiEWbxYq8RPB2BXcA3LgiDiGLNJRJ Dvm8fZ1gCYeCNeCyoZmOfFXSUApvL1m4TcYH84JvhCosAgCK6vGEk+LZq5qjZJhnDfvs 5PxjrR/8RDd7qhxPDfMH4JIK6pXK/9f00XWOwZjiS688Z2oxU66dDJlb5GpdYsrqJ5F6 ZoEqbThgU0iXT/WMKIu04TZAQTYO8H1N/sq413uDaT92TiaG4xppUuewLFGQgoNNoLab ayCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@163.com header.s=s110527 header.b=KGETv7MY; 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=163.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kr14-20020a170903080e00b0019cf7f260acsi6363379plb.329.2023.03.13.02.34.21; Mon, 13 Mar 2023 02:34:35 -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=@163.com header.s=s110527 header.b=KGETv7MY; 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=163.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230047AbjCMJGf (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Mon, 13 Mar 2023 05:06:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230005AbjCMJGN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 13 Mar 2023 05:06:13 -0400 Received: from m12.mail.163.com (m12.mail.163.com [220.181.12.215]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1F5F2126DA; Mon, 13 Mar 2023 02:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=Gp4+C 4gCMjSOFnYU898NA74fjHaBuOlyPKxcR6f/MrM=; b=KGETv7MYHU+IHxw98BaBR VDQdxpMYuwdI1zU0dSr77DawJfbRVpRuAa0fgLiQwAxWr3trRXIyDtCzcrX1TD5f naMFYoZ39uhUIHbo6a2mEgnQ3hC+dMZ3QXhHe4GFxefMpqA3DwnqwItVIKaYqQYU gXBFT+1IfXoEjwX0xtGnXQ= Received: from leanderwang-LC2.localdomain (unknown [111.206.145.21]) by zwqz-smtp-mta-g0-3 (Coremail) with SMTP id _____wDXOaAT5g5kXWohAA--.8836S2; Mon, 13 Mar 2023 17:00:04 +0800 (CST) From: Zheng Wang <zyytlz.wz@163.com> To: ericvh@gmail.com Cc: lucho@ionkov.net, asmadeus@codewreck.org, linux_oss@crudebyte.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, hackerzheng666@gmail.com, 1395428693sheep@gmail.com, alex000young@gmail.com, Zheng Wang <zyytlz.wz@163.com> Subject: [PATCH net v2] 9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition Date: Mon, 13 Mar 2023 17:00:02 +0800 Message-Id: <20230313090002.3308025-1-zyytlz.wz@163.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: _____wDXOaAT5g5kXWohAA--.8836S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7tF15Cw48JFy5Kr1kWF4DJwb_yoW8Xw1xpa nakFWrAFyUA3WjyFsYyas7G3WrCw4rGr1Iga12kw4fJr98Jry8XFZ5t34Yg345Ar4YqF1r Cw1UWFWDJFWDZw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0ziID73UUUUU= X-Originating-IP: [111.206.145.21] X-CM-SenderInfo: h2113zf2oz6qqrwthudrp/1tbiXRoxU1WBo5B68QAAsJ X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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?1760244610823808223?= X-GMAIL-MSGID: =?utf-8?q?1760244610823808223?= |
Series |
[net,v2] 9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition
|
|
Commit Message
Zheng Wang
March 13, 2023, 9 a.m. UTC
In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring
to init priv->rings and bound &ring->work with p9_xen_response.
When it calls xen_9pfs_front_event_handler to handle IRQ requests,
it will finally call schedule_work to start the work.
When we call xen_9pfs_front_remove to remove the driver, there
may be a sequence as follows:
Fix it by finishing the work before cleanup in xen_9pfs_front_free.
Note that, this bug is found by static analysis, which might be
false positive.
CPU0 CPU1
|p9_xen_response
xen_9pfs_front_remove|
xen_9pfs_front_free|
kfree(priv) |
//free priv |
|p9_tag_lookup
|//use priv->client
Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
---
v2:
- fix type error of ring found by kernel test robot
---
net/9p/trans_xen.c | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Mon, Mar 13, 2023 at 05:00:02PM +0800, Zheng Wang wrote: > In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring > to init priv->rings and bound &ring->work with p9_xen_response. > > When it calls xen_9pfs_front_event_handler to handle IRQ requests, > it will finally call schedule_work to start the work. > > When we call xen_9pfs_front_remove to remove the driver, there > may be a sequence as follows: > > Fix it by finishing the work before cleanup in xen_9pfs_front_free. > > Note that, this bug is found by static analysis, which might be > false positive. > > CPU0 CPU1 > > |p9_xen_response > xen_9pfs_front_remove| > xen_9pfs_front_free| > kfree(priv) | > //free priv | > |p9_tag_lookup > |//use priv->client > > Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend") > Signed-off-by: Zheng Wang <zyytlz.wz@163.com> > --- > v2: > - fix type error of ring found by kernel test robot > --- > net/9p/trans_xen.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c > index c64050e839ac..83764431c066 100644 > --- a/net/9p/trans_xen.c > +++ b/net/9p/trans_xen.c > @@ -274,12 +274,17 @@ static const struct xenbus_device_id xen_9pfs_front_ids[] = { > static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > { > int i, j; > + struct xen_9pfs_dataring *ring = NULL; Move it before int i, j to have RCT. > > write_lock(&xen_9pfs_lock); > list_del(&priv->list); > write_unlock(&xen_9pfs_lock); > > for (i = 0; i < priv->num_rings; i++) { > + /*cancel work*/ It isn't needed I think, the function cancel_work_sync() tells everything here. > + ring = &priv->rings[i]; > + cancel_work_sync(&ring->work); > + > if (!priv->rings[i].intf) > break; > if (priv->rings[i].irq > 0) > -- > 2.25.1
Michal Swiatkowski <michal.swiatkowski@linux.intel.com> 于2023年3月13日周一 21:54写道: > > On Mon, Mar 13, 2023 at 05:00:02PM +0800, Zheng Wang wrote: > > In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring > > to init priv->rings and bound &ring->work with p9_xen_response. > > > > When it calls xen_9pfs_front_event_handler to handle IRQ requests, > > it will finally call schedule_work to start the work. > > > > When we call xen_9pfs_front_remove to remove the driver, there > > may be a sequence as follows: > > > > Fix it by finishing the work before cleanup in xen_9pfs_front_free. > > > > Note that, this bug is found by static analysis, which might be > > false positive. > > > > CPU0 CPU1 > > > > |p9_xen_response > > xen_9pfs_front_remove| > > xen_9pfs_front_free| > > kfree(priv) | > > //free priv | > > |p9_tag_lookup > > |//use priv->client > > > > Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend") > > Signed-off-by: Zheng Wang <zyytlz.wz@163.com> > > --- > > v2: > > - fix type error of ring found by kernel test robot > > --- > > net/9p/trans_xen.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c > > index c64050e839ac..83764431c066 100644 > > --- a/net/9p/trans_xen.c > > +++ b/net/9p/trans_xen.c > > @@ -274,12 +274,17 @@ static const struct xenbus_device_id xen_9pfs_front_ids[] = { > > static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > { > > int i, j; > > + struct xen_9pfs_dataring *ring = NULL; > Move it before int i, j to have RCT. > > > > > write_lock(&xen_9pfs_lock); > > list_del(&priv->list); > > write_unlock(&xen_9pfs_lock); > > > > for (i = 0; i < priv->num_rings; i++) { > > + /*cancel work*/ > It isn't needed I think, the function cancel_work_sync() tells everything > here. > Get it, will remove it in the next version of patch. Best regards, Zheng
On Mon, Mar 13, 2023 at 10:01:21PM +0800, Zheng Hacker wrote: > Michal Swiatkowski <michal.swiatkowski@linux.intel.com> 于2023年3月13日周一 21:54写道: > > > > On Mon, Mar 13, 2023 at 05:00:02PM +0800, Zheng Wang wrote: > > > In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring > > > to init priv->rings and bound &ring->work with p9_xen_response. > > > > > > When it calls xen_9pfs_front_event_handler to handle IRQ requests, > > > it will finally call schedule_work to start the work. > > > > > > When we call xen_9pfs_front_remove to remove the driver, there > > > may be a sequence as follows: > > > > > > Fix it by finishing the work before cleanup in xen_9pfs_front_free. > > > > > > Note that, this bug is found by static analysis, which might be > > > false positive. > > > > > > CPU0 CPU1 > > > > > > |p9_xen_response > > > xen_9pfs_front_remove| > > > xen_9pfs_front_free| > > > kfree(priv) | > > > //free priv | > > > |p9_tag_lookup > > > |//use priv->client > > > > > > Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend") > > > Signed-off-by: Zheng Wang <zyytlz.wz@163.com> > > > --- > > > v2: > > > - fix type error of ring found by kernel test robot > > > --- > > > net/9p/trans_xen.c | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c > > > index c64050e839ac..83764431c066 100644 > > > --- a/net/9p/trans_xen.c > > > +++ b/net/9p/trans_xen.c > > > @@ -274,12 +274,17 @@ static const struct xenbus_device_id xen_9pfs_front_ids[] = { > > > static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > > { > > > int i, j; > > > + struct xen_9pfs_dataring *ring = NULL; > > Move it before int i, j to have RCT. > > Sorry I didn't notice it before, move the definition to for loop. > > > > > > write_lock(&xen_9pfs_lock); > > > list_del(&priv->list); > > > write_unlock(&xen_9pfs_lock); > > > > > > for (i = 0; i < priv->num_rings; i++) { Here: struct xen_9pfs_dataring *ring = &priv->rings[i]; > > > + /*cancel work*/ > > It isn't needed I think, the function cancel_work_sync() tells everything > > here. > > > > Get it, will remove it in the next version of patch. > > Best regards, > Zheng
Michal Swiatkowski <michal.swiatkowski@linux.intel.com> 于2023年3月13日周一 22:08写道: > > On Mon, Mar 13, 2023 at 10:01:21PM +0800, Zheng Hacker wrote: > > Michal Swiatkowski <michal.swiatkowski@linux.intel.com> 于2023年3月13日周一 21:54写道: > > > > > > On Mon, Mar 13, 2023 at 05:00:02PM +0800, Zheng Wang wrote: > > > > In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring > > > > to init priv->rings and bound &ring->work with p9_xen_response. > > > > > > > > When it calls xen_9pfs_front_event_handler to handle IRQ requests, > > > > it will finally call schedule_work to start the work. > > > > > > > > When we call xen_9pfs_front_remove to remove the driver, there > > > > may be a sequence as follows: > > > > > > > > Fix it by finishing the work before cleanup in xen_9pfs_front_free. > > > > > > > > Note that, this bug is found by static analysis, which might be > > > > false positive. > > > > > > > > CPU0 CPU1 > > > > > > > > |p9_xen_response > > > > xen_9pfs_front_remove| > > > > xen_9pfs_front_free| > > > > kfree(priv) | > > > > //free priv | > > > > |p9_tag_lookup > > > > |//use priv->client > > > > > > > > Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend") > > > > Signed-off-by: Zheng Wang <zyytlz.wz@163.com> > > > > --- > > > > v2: > > > > - fix type error of ring found by kernel test robot > > > > --- > > > > net/9p/trans_xen.c | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c > > > > index c64050e839ac..83764431c066 100644 > > > > --- a/net/9p/trans_xen.c > > > > +++ b/net/9p/trans_xen.c > > > > @@ -274,12 +274,17 @@ static const struct xenbus_device_id xen_9pfs_front_ids[] = { > > > > static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > > > { > > > > int i, j; > > > > + struct xen_9pfs_dataring *ring = NULL; > > > Move it before int i, j to have RCT. > > > > Sorry I didn't notice it before, move the definition to for loop. > Get it, will correct it in the next patch. Thanks for your notice :) > > > > > > > > write_lock(&xen_9pfs_lock); > > > > list_del(&priv->list); > > > > write_unlock(&xen_9pfs_lock); > > > > > > > > for (i = 0; i < priv->num_rings; i++) { > Here: > struct xen_9pfs_dataring *ring = &priv->rings[i]; > Best regards, Zheng
On Mon, 13 Mar 2023 14:54:20 +0100 Michal Swiatkowski wrote: > > @@ -274,12 +274,17 @@ static const struct xenbus_device_id xen_9pfs_front_ids[] = { > > static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > { > > int i, j; > > + struct xen_9pfs_dataring *ring = NULL; > Move it before int i, j to have RCT. > > > > > write_lock(&xen_9pfs_lock); > > list_del(&priv->list); > > write_unlock(&xen_9pfs_lock); > > > > for (i = 0; i < priv->num_rings; i++) { > > + /*cancel work*/ > It isn't needed I think, the function cancel_work_sync() tells everything > here. Note that 9p is more storage than networking, so this patch is likely to go via a different tree than us.
Jakub Kicinski wrote on Mon, Mar 13, 2023 at 02:30:54PM -0700: > On Mon, 13 Mar 2023 14:54:20 +0100 Michal Swiatkowski wrote: > > > for (i = 0; i < priv->num_rings; i++) { > > > + /*cancel work*/ > > It isn't needed I think, the function cancel_work_sync() tells everything > > here. > > Note that 9p is more storage than networking, so this patch is likely > to go via a different tree than us. Any review done is useful anyway ;) Either Eric or me will take the patch, but in the past such fixes have sometimes also been taken into the net tree; honestly I wouldn't mind a bit more "rule" here as it's a bit weird that some of our patches are Cc to fsdevel@ (fs/ from fs/9p) and the other half netdev@ (net/ from net/9p), but afaict the MAINTAINERS syntax doesn't have a way of excluding e.g. net/9p from the `NETWORKING [GENERAL]` group so I guess we just have to live with that. There's little enough volume and netdev automation sends a mail when a patch is picked up, so as long as there's no conflict (large majority of the cases) such fixes can go either way as far as I'm concerned.
Jakub Kicinski <kuba@kernel.org> 于2023年3月14日周二 05:30写道: > > On Mon, 13 Mar 2023 14:54:20 +0100 Michal Swiatkowski wrote: > > > @@ -274,12 +274,17 @@ static const struct xenbus_device_id xen_9pfs_front_ids[] = { > > > static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > > { > > > int i, j; > > > + struct xen_9pfs_dataring *ring = NULL; > > Move it before int i, j to have RCT. > > > > > > > > write_lock(&xen_9pfs_lock); > > > list_del(&priv->list); > > > write_unlock(&xen_9pfs_lock); > > > > > > for (i = 0; i < priv->num_rings; i++) { > > > + /*cancel work*/ > > It isn't needed I think, the function cancel_work_sync() tells everything > > here. > > Note that 9p is more storage than networking, so this patch is likely > to go via a different tree than us. Sorry I got confused. Best regards, Zheng
<asmadeus@codewreck.org> 于2023年3月14日周二 06:08写道: > > Jakub Kicinski wrote on Mon, Mar 13, 2023 at 02:30:54PM -0700: > > On Mon, 13 Mar 2023 14:54:20 +0100 Michal Swiatkowski wrote: > > > > for (i = 0; i < priv->num_rings; i++) { > > > > + /*cancel work*/ > > > It isn't needed I think, the function cancel_work_sync() tells everything > > > here. > > > > Note that 9p is more storage than networking, so this patch is likely > > to go via a different tree than us. > > Any review done is useful anyway ;) > > Either Eric or me will take the patch, but in the past such fixes have > sometimes also been taken into the net tree; honestly I wouldn't mind a > bit more "rule" here as it's a bit weird that some of our patches are Cc > to fsdevel@ (fs/ from fs/9p) and the other half netdev@ (net/ from > net/9p), but afaict the MAINTAINERS syntax doesn't have a way of > excluding e.g. net/9p from the `NETWORKING [GENERAL]` group so I guess > we just have to live with that. Dear Dominique, Sorry for my confusion and thanks for your patient explanation. I'll take care of it when submitting a fix to the linux kernel in the future. > > There's little enough volume and netdev automation sends a mail when a > patch is picked up, so as long as there's no conflict (large majority of > the cases) such fixes can go either way as far as I'm concerned. > Thanks again for your effort. Hope you have a good day :) Best regards, Zheng
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c index c64050e839ac..83764431c066 100644 --- a/net/9p/trans_xen.c +++ b/net/9p/trans_xen.c @@ -274,12 +274,17 @@ static const struct xenbus_device_id xen_9pfs_front_ids[] = { static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) { int i, j; + struct xen_9pfs_dataring *ring = NULL; write_lock(&xen_9pfs_lock); list_del(&priv->list); write_unlock(&xen_9pfs_lock); for (i = 0; i < priv->num_rings; i++) { + /*cancel work*/ + ring = &priv->rings[i]; + cancel_work_sync(&ring->work); + if (!priv->rings[i].intf) break; if (priv->rings[i].irq > 0)