From: Andi Shyti <andi.shyti@kernel.org>
To: lm0963 <lm0963hack@gmail.com>
Cc: inki.dae@samsung.com, sw0312.kim@samsung.com,
kyungmin.park@samsung.com, airlied@gmail.com, daniel@ffwll.ch,
krzysztof.kozlowski@linaro.org, alim.akhtar@samsung.com,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl
Date: Wed, 31 May 2023 14:05:31 +0200 [thread overview]
Message-ID: <20230531120531.dynd3iyggauucly7@intel.intel> (raw)
In-Reply-To: <CAAgLYK4KzuKMTkBwzCJj4wa+W+=9fR+A1J=XR-n1E-W7EjexuA@mail.gmail.com>
Hi Min,
On Wed, May 31, 2023 at 06:54:34PM +0800, lm0963 wrote:
> Hi Andi,
>
> On Wed, May 31, 2023 at 4:19 PM Andi Shyti <andi.shyti@kernel.org> wrote:
> >
> > Hi Min,
> >
> > > > > If it is async, runqueue_node is freed in g2d_runqueue_worker on another
> > > > > worker thread. So in extreme cases, if g2d_runqueue_worker runs first, and
> > > > > then executes the following if statement, there will be use-after-free.
> > > > >
> > > > > Signed-off-by: Min Li <lm0963hack@gmail.com>
> > > > > ---
> > > > > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > > > > index ec784e58da5c..414e585ec7dd 100644
> > > > > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > > > > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > > > > @@ -1335,7 +1335,7 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev, void *data,
> > > > > /* Let the runqueue know that there is work to do. */
> > > > > queue_work(g2d->g2d_workq, &g2d->runqueue_work);
> > > > >
> > > > > - if (runqueue_node->async)
> > > > > + if (req->async)
> > > >
> > > > did you actually hit this? If you did, then the fix is not OK.
> > >
> > > No, I didn't actually hit this. I found it through code review. This
> > > is only a theoretical issue that can only be triggered in extreme
> > > cases.
> >
> > first of all runqueue is used again two lines below this, which
> > means that if you don't hit the uaf here you will hit it
> > immediately after.
>
> No, if async is true, then it will goto out, which will directly return.
>
> if (runqueue_node->async)
> goto out; // here, go to out, will directly return
>
> wait_for_completion(&runqueue_node->complete); // not hit
> g2d_free_runqueue_node(g2d, runqueue_node);
>
> out:
> return 0;
that's right, sorry, I misread it.
> > Second, if runqueue is freed, than we need to remove the part
> > where it's freed because it doesn't make sense to free runqueue
> > at this stage.
>
> It is freed by g2d_free_runqueue_node in g2d_runqueue_worker
>
> static void g2d_runqueue_worker(struct work_struct *work)
> {
> ......
> if (runqueue_node) {
> pm_runtime_mark_last_busy(g2d->dev);
> pm_runtime_put_autosuspend(g2d->dev);
>
> complete(&runqueue_node->complete);
> if (runqueue_node->async)
> g2d_free_runqueue_node(g2d, runqueue_node); // freed here
this is what I'm wondering: is it correct to free a resource
here? The design looks to me a bit fragile and prone to mistakes.
The patch per se is OK. It doesn't make much difference to me
where you actually read async, although this patch looks a bit
safer:
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
However some refactoring might be needed to make it a bit more
robust.
Thanks,
Andi
> }
>
> >
> > Finally, can you elaborate on the code review that you did so
> > that we all understand it?
>
> queue_work(g2d->g2d_workq, &g2d->runqueue_work);
> msleep(100); // add sleep here to let g2d_runqueue_worker run first
> if (runqueue_node->async)
> goto out;
>
>
> >
> > Andi
>
>
>
> --
> Min Li
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-05-31 12:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230527081826epcas1p15ec3fca591d914aff2019ddf7fd1d59c@epcas1p1.samsung.com>
2023-05-26 13:01 ` [PATCH] drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl Min Li
2023-05-30 22:21 ` Andi Shyti
2023-05-31 4:39 ` lm0963
2023-05-31 8:19 ` Andi Shyti
2023-05-31 10:54 ` lm0963
2023-05-31 12:05 ` Andi Shyti [this message]
2023-05-31 22:55 ` 대인기/Tizen Platform Lab(SR)/삼성전자
2023-06-01 8:29 ` Andi Shyti
2023-06-02 1:20 ` 대인기/Tizen Platform Lab(SR)/삼성전자
2023-05-31 7:45 ` 대인기/Tizen Platform Lab(SR)/삼성전자
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230531120531.dynd3iyggauucly7@intel.intel \
--to=andi.shyti@kernel.org \
--cc=airlied@gmail.com \
--cc=alim.akhtar@samsung.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=lm0963hack@gmail.com \
--cc=sw0312.kim@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox