Message ID | 20230313154132.3684181-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 v21csp1281543wrd; Mon, 13 Mar 2023 09:30:22 -0700 (PDT) X-Google-Smtp-Source: AK7set8Ug3NQNdIoGUO0mTTYa65f0tcHlnhggaUkXtGzf/cGr9DB9I0dQt2FMqVVl2etzasJ5Fxw X-Received: by 2002:a17:90a:4618:b0:23b:4c0a:edb1 with SMTP id w24-20020a17090a461800b0023b4c0aedb1mr6470784pjg.15.1678725021796; Mon, 13 Mar 2023 09:30:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678725021; cv=none; d=google.com; s=arc-20160816; b=s9XB9Iwbtj2KQggjgY5BtppqIeqj4CKbNrDOXMI685rQ4hRfVAVgl+fmrRgNBooMoL +4uP9zGKgfMfrCYkyK8LT3rO2Iab7f21wVNmmZl/+8ksiDKRhlckuj5C4PxGIE5QMfl/ Efddfl+dhDY5tOTT3LMuHePMbWsDxHVWagQzSX0LhF4d4sqh+5QqBvqt2lqYDY3+8wrf 3MTwrfLMrTNKnbj+yqNmRFN5e6TThaU7Lfvc8jUAlEAFPkvM4GlFo1uiRaI5TdosBwnZ gm+sMWNQXU8c6pGwsWwNE9detsdiYpIPvvvkLvM63eFNUl/U8LzupIvo1N3OoWjGBFVI 2V9Q== 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=NMeHqc9vEtUERKAOCOKjGmVkf5YkMepOMEfhtaswEhc=; b=pinyy5gqmbZVouMXPZOumbYgklCnCjgpDtKvcUgTst2To40+SiFJvgpw/iggYOY6CE fYXz6QUmquxq0fxuUZr56neGFY6t/oSIxKE3X0OY9Gig4fdIrAfHDCaMWDn5T9LNbQW1 kBlelTfjHhavSZ03LX0POw1wW/N4SZkK9D+aZEPK1osL/XDL3mpbl0SotwJH4Phmo1O3 Il806swvsb6tuUh/86bbYuYIvuKqr9QR0YKFT7ZKVrI4qJ8XiRCZ0W2+sKIav30AFZuv D5G0yioZJZ/EugsfR6JseUQJAE+veYU43eWKeBwBsMQK0a/EQGQZY7e1HOzzm8zVVpRy QeHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@163.com header.s=s110527 header.b=em7N6x0m; 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 m8-20020a635808000000b005032da2e5c3si7056881pgb.252.2023.03.13.09.30.06; Mon, 13 Mar 2023 09:30:21 -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=em7N6x0m; 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 S229832AbjCMPmK (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Mon, 13 Mar 2023 11:42:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229543AbjCMPmI (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 13 Mar 2023 11:42:08 -0400 Received: from m12.mail.163.com (m12.mail.163.com [123.126.96.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5057D53724; Mon, 13 Mar 2023 08:42:05 -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=NMeHq c9vEtUERKAOCOKjGmVkf5YkMepOMEfhtaswEhc=; b=em7N6x0m+8FcZgIVUSuhU HnWkEZhrTFz+w29FDBYiesKxWe2N5jlOOVn09DuSUMytcqnF4H1qqS7iWTZ5evNM OwyRpJDpK7FBbt97Eu24mZFq9vEpchwN3RErZboGOkViLFU8wIG1YCIW6ydh/G1E YBdeRU+aC1FoaJB0JglJ9M= Received: from leanderwang-LC2.localdomain (unknown [111.206.145.21]) by smtp19 (Coremail) with SMTP id R9xpCgD3_rItRA9kgCPoHQ--.36544S2; Mon, 13 Mar 2023 23:41:33 +0800 (CST) From: Zheng Wang <zyytlz.wz@163.com> To: ezequiel@vanguardiasur.com.ar Cc: p.zabel@pengutronix.de, mchehab@kernel.org, linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, hackerzheng666@gmail.com, 1395428693sheep@gmail.com, alex000young@gmail.com, hverkuil@xs4all.nl, Zheng Wang <zyytlz.wz@163.com> Subject: [PATCH v3] media: hantro: fix use after free bug in hantro_remove due to race condition Date: Mon, 13 Mar 2023 23:41:32 +0800 Message-Id: <20230313154132.3684181-1-zyytlz.wz@163.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: R9xpCgD3_rItRA9kgCPoHQ--.36544S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7Wry3Xw4kJw47Jr4rWr4kZwb_yoW8Cw1DpF W3G3y5KrWjqr47KFn7tay09ayfCasFqF4jgrZruw13JF9xtr9rurySyF48AF98JrZ3ZF4a vF4jqrW8Z3y2vFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0ziaZXrUUUUU= X-Originating-IP: [111.206.145.21] X-CM-SenderInfo: h2113zf2oz6qqrwthudrp/xtbBzgsxU2I0XntM5AADs- 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, RCVD_IN_DNSWL_NONE,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?1760270665715627796?= X-GMAIL-MSGID: =?utf-8?q?1760270768789942384?= |
Series |
[v3] media: hantro: fix use after free bug in hantro_remove due to race condition
|
|
Commit Message
Zheng Wang
March 13, 2023, 3:41 p.m. UTC
In hantro_probe, vpu->watchdog_work is bound with
hantro_watchdog. Then hantro_end_prepare_run may
be called to start the work.
If we close the file or remove the module which will
call hantro_release and hantro_remove to make cleanup,
there may be an unfinished work. The possible sequence
is as follows, which will cause a typical UAF bug.
The same thing will happen in hantro_release, and use
ctx after freeing it.
Fix it by canceling the work before cleanup in hantro_release.
CPU0 CPU1
|hantro_watchdog
hantro_remove |
v4l2_m2m_release |
kfree(m2m_dev); |
|
| v4l2_m2m_get_curr_priv
| m2m_dev->curr_ctx //use
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
---
v3:
- use cancel_delayed_work_sync instead of cancel_delayed_work and add it to
hantro_release suggested by Hans Verkuil
v2:
- move the cancel-work-related code to hantro_remove suggested by Hans Verkuil
---
drivers/media/platform/verisilicon/hantro_drv.c | 2 ++
1 file changed, 2 insertions(+)
Comments
Hi Zheng, On Mon, Mar 13, 2023 at 12:42 PM Zheng Wang <zyytlz.wz@163.com> wrote: > > In hantro_probe, vpu->watchdog_work is bound with > hantro_watchdog. Then hantro_end_prepare_run may > be called to start the work. > > If we close the file or remove the module which will > call hantro_release and hantro_remove to make cleanup, It's not possible to close the file or remove the module while a watchdog is scheduled. That's because the watchdog is active only during a mem2mem job, and the file won't be closed until the job is done. v4l2_m2m_ctx_release calls v4l2_m2m_cancel_jobw which waits until the job is done. If you can confirm it's possible to remove or close the file while a job is running, that would be a driver bug. Thanks for the patch, but it's not needed. Regards, Ezequiel > there may be an unfinished work. The possible sequence > is as follows, which will cause a typical UAF bug. > > The same thing will happen in hantro_release, and use > ctx after freeing it. > > Fix it by canceling the work before cleanup in hantro_release. > > CPU0 CPU1 > > |hantro_watchdog > hantro_remove | > v4l2_m2m_release | > kfree(m2m_dev); | > | > | v4l2_m2m_get_curr_priv > | m2m_dev->curr_ctx //use > > Signed-off-by: Zheng Wang <zyytlz.wz@163.com> > --- > v3: > - use cancel_delayed_work_sync instead of cancel_delayed_work and add it to > hantro_release suggested by Hans Verkuil > > v2: > - move the cancel-work-related code to hantro_remove suggested by Hans Verkuil > --- > drivers/media/platform/verisilicon/hantro_drv.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c > index b0aeedae7b65..86a4c0fa8c7d 100644 > --- a/drivers/media/platform/verisilicon/hantro_drv.c > +++ b/drivers/media/platform/verisilicon/hantro_drv.c > @@ -597,6 +597,7 @@ static int hantro_release(struct file *filp) > struct hantro_ctx *ctx = > container_of(filp->private_data, struct hantro_ctx, fh); > > + cancel_delayed_work_sync(&ctx->dev->watchdog_work); > /* > * No need for extra locking because this was the last reference > * to this file. > @@ -1099,6 +1100,7 @@ static int hantro_remove(struct platform_device *pdev) > > v4l2_info(&vpu->v4l2_dev, "Removing %s\n", pdev->name); > > + cancel_delayed_work_sync(&vpu->watchdog_work); > media_device_unregister(&vpu->mdev); > hantro_remove_dec_func(vpu); > hantro_remove_enc_func(vpu); > -- > 2.25.1 >
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> 于2023年3月31日周五 10:38写道: > > Hi Zheng, > > On Mon, Mar 13, 2023 at 12:42 PM Zheng Wang <zyytlz.wz@163.com> wrote: > > > > In hantro_probe, vpu->watchdog_work is bound with > > hantro_watchdog. Then hantro_end_prepare_run may > > be called to start the work. > > > > If we close the file or remove the module which will > > call hantro_release and hantro_remove to make cleanup, > > It's not possible to close the file or remove the module while a watchdog is > scheduled. > > That's because the watchdog is active only during a mem2mem job, > and the file won't be closed until the job is done. > > v4l2_m2m_ctx_release calls v4l2_m2m_cancel_jobw > which waits until the job is done. > > If you can confirm it's possible to remove or close the file > while a job is running, that would be a driver bug. > > Thanks for the patch, but it's not needed. > Hi Ezequiel, Thanks for your detailed analysis. Got it :) Best regards, Zheng > Regards, > Ezequiel > > > there may be an unfinished work. The possible sequence > > is as follows, which will cause a typical UAF bug. > > > > The same thing will happen in hantro_release, and use > > ctx after freeing it. > > > > Fix it by canceling the work before cleanup in hantro_release. > > > > CPU0 CPU1 > > > > |hantro_watchdog > > hantro_remove | > > v4l2_m2m_release | > > kfree(m2m_dev); | > > | > > | v4l2_m2m_get_curr_priv > > | m2m_dev->curr_ctx //use > > > > Signed-off-by: Zheng Wang <zyytlz.wz@163.com> > > --- > > v3: > > - use cancel_delayed_work_sync instead of cancel_delayed_work and add it to > > hantro_release suggested by Hans Verkuil > > > > v2: > > - move the cancel-work-related code to hantro_remove suggested by Hans Verkuil > > --- > > drivers/media/platform/verisilicon/hantro_drv.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c > > index b0aeedae7b65..86a4c0fa8c7d 100644 > > --- a/drivers/media/platform/verisilicon/hantro_drv.c > > +++ b/drivers/media/platform/verisilicon/hantro_drv.c > > @@ -597,6 +597,7 @@ static int hantro_release(struct file *filp) > > struct hantro_ctx *ctx = > > container_of(filp->private_data, struct hantro_ctx, fh); > > > > + cancel_delayed_work_sync(&ctx->dev->watchdog_work); > > /* > > * No need for extra locking because this was the last reference > > * to this file. > > @@ -1099,6 +1100,7 @@ static int hantro_remove(struct platform_device *pdev) > > > > v4l2_info(&vpu->v4l2_dev, "Removing %s\n", pdev->name); > > > > + cancel_delayed_work_sync(&vpu->watchdog_work); > > media_device_unregister(&vpu->mdev); > > hantro_remove_dec_func(vpu); > > hantro_remove_enc_func(vpu); > > -- > > 2.25.1 > >
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c index b0aeedae7b65..86a4c0fa8c7d 100644 --- a/drivers/media/platform/verisilicon/hantro_drv.c +++ b/drivers/media/platform/verisilicon/hantro_drv.c @@ -597,6 +597,7 @@ static int hantro_release(struct file *filp) struct hantro_ctx *ctx = container_of(filp->private_data, struct hantro_ctx, fh); + cancel_delayed_work_sync(&ctx->dev->watchdog_work); /* * No need for extra locking because this was the last reference * to this file. @@ -1099,6 +1100,7 @@ static int hantro_remove(struct platform_device *pdev) v4l2_info(&vpu->v4l2_dev, "Removing %s\n", pdev->name); + cancel_delayed_work_sync(&vpu->watchdog_work); media_device_unregister(&vpu->mdev); hantro_remove_dec_func(vpu); hantro_remove_enc_func(vpu);