From: "Christian König" <christian.koenig@amd.com>
To: Asahi Lina <lina@asahilina.net>,
Luben Tuikov <luben.tuikov@amd.com>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: Faith Ekstrand <faith.ekstrand@collabora.com>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, asahi@lists.linux.dev
Subject: Re: [PATCH 2/3] drm/scheduler: Fix UAF in drm_sched_fence_get_timeline_name
Date: Fri, 14 Jul 2023 10:43:48 +0200 [thread overview]
Message-ID: <bef7ef62-3cd9-6ceb-5eb4-5ae0c0236778@amd.com> (raw)
In-Reply-To: <20230714-drm-sched-fixes-v1-2-c567249709f7@asahilina.net>
Am 14.07.23 um 10:21 schrieb Asahi Lina:
> A signaled scheduler fence can outlive its scheduler, since fences are
> independencly reference counted. Therefore, we can't reference the
> scheduler in the get_timeline_name() implementation.
>
> Fixes oopses on `cat /sys/kernel/debug/dma_buf/bufinfo` when shared
> dma-bufs reference fences from GPU schedulers that no longer exist.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 7 ++++++-
> drivers/gpu/drm/scheduler/sched_fence.c | 4 +++-
> include/drm/gpu_scheduler.h | 5 +++++
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
> index b2bbc8a68b30..17f35b0b005a 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -389,7 +389,12 @@ static bool drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
>
> /*
> * Fence is from the same scheduler, only need to wait for
> - * it to be scheduled
> + * it to be scheduled.
> + *
> + * Note: s_fence->sched could have been freed and reallocated
> + * as another scheduler. This false positive case is okay, as if
> + * the old scheduler was freed all of its jobs must have
> + * signaled their completion fences.
This is outright nonsense. As long as an entity for a scheduler exists
it is not allowed to free up this scheduler.
So this function can't be called like this.
> */
> fence = dma_fence_get(&s_fence->scheduled);
> dma_fence_put(entity->dependency);
> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c
> index ef120475e7c6..06a0eebcca10 100644
> --- a/drivers/gpu/drm/scheduler/sched_fence.c
> +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> @@ -68,7 +68,7 @@ static const char *drm_sched_fence_get_driver_name(struct dma_fence *fence)
> static const char *drm_sched_fence_get_timeline_name(struct dma_fence *f)
> {
> struct drm_sched_fence *fence = to_drm_sched_fence(f);
> - return (const char *)fence->sched->name;
> + return (const char *)fence->sched_name;
> }
>
> static void drm_sched_fence_free_rcu(struct rcu_head *rcu)
> @@ -216,6 +216,8 @@ void drm_sched_fence_init(struct drm_sched_fence *fence,
> unsigned seq;
>
> fence->sched = entity->rq->sched;
> + strlcpy(fence->sched_name, entity->rq->sched->name,
> + sizeof(fence->sched_name));
> seq = atomic_inc_return(&entity->fence_seq);
> dma_fence_init(&fence->scheduled, &drm_sched_fence_ops_scheduled,
> &fence->lock, entity->fence_context, seq);
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index e95b4837e5a3..4fa9523bd47d 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -305,6 +305,11 @@ struct drm_sched_fence {
> * @lock: the lock used by the scheduled and the finished fences.
> */
> spinlock_t lock;
> + /**
> + * @sched_name: the name of the scheduler that owns this fence. We
> + * keep a copy here since fences can outlive their scheduler.
> + */
> + char sched_name[16];
This just mitigates the problem, but doesn't fix it.
The real issue is that the hw fence is kept around much longer than that.
Additional to that I'm not willing to increase the scheduler fence size
like that just to decouple them from the scheduler.
Regards,
Christian.
> /**
> * @owner: job owner for debugging
> */
>
next prev parent reply other threads:[~2023-07-14 8:44 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 8:21 [PATCH 0/3] DRM scheduler documentation & bug fixes Asahi Lina
2023-07-14 8:21 ` [PATCH 1/3] drm/scheduler: Add more documentation Asahi Lina
2023-07-14 8:40 ` Christian König
2023-07-14 9:39 ` Asahi Lina
2023-07-14 9:47 ` Christian König
2023-07-14 9:51 ` Asahi Lina
2023-07-14 8:21 ` [PATCH 2/3] drm/scheduler: Fix UAF in drm_sched_fence_get_timeline_name Asahi Lina
2023-07-14 8:43 ` Christian König [this message]
2023-07-14 9:44 ` Asahi Lina
2023-07-14 9:51 ` Christian König
2023-07-14 10:07 ` Asahi Lina
2023-07-14 10:29 ` Christian König
2023-07-14 9:49 ` Asahi Lina
2023-07-14 9:57 ` Christian König
2023-07-14 10:06 ` Asahi Lina
2023-07-14 10:18 ` Christian König
2023-07-14 12:13 ` Asahi Lina
2023-07-15 4:03 ` Luben Tuikov
2023-07-15 14:14 ` alyssa
2023-07-17 15:55 ` Christian König
2023-07-18 2:35 ` Asahi Lina
2023-07-18 5:45 ` Luben Tuikov
2023-07-21 10:33 ` Asahi Lina
2023-07-31 8:09 ` Christian König
2023-11-01 6:59 ` Dave Airlie
2023-11-01 8:13 ` Daniel Vetter
2023-11-02 10:48 ` Christian König
2023-11-02 11:19 ` Lucas Stach
2023-11-02 12:39 ` Christian König
2023-07-28 7:48 ` Christian König
2023-07-18 8:21 ` Pekka Paalanen
2023-07-14 8:21 ` [PATCH 3/3] drm/scheduler: Clean up jobs when the scheduler is torn down Asahi Lina
2023-07-15 7:14 ` Luben Tuikov
2023-07-16 7:51 ` Asahi Lina
2023-07-17 17:40 ` Luben Tuikov
2023-07-17 22:45 ` Asahi Lina
2023-07-18 5:14 ` Luben Tuikov
2023-07-19 18:16 ` Konstantin Ryabitsev
2023-07-19 18:58 ` Luben Tuikov
2023-08-02 4:06 ` Matthew Brost
2023-08-02 14:12 ` Luben Tuikov
2023-07-19 8:45 ` Christian König
2023-07-19 15:05 ` Luben Tuikov
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=bef7ef62-3cd9-6ceb-5eb4-5ae0c0236778@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=alyssa@rosenzweig.io \
--cc=asahi@lists.linux.dev \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=faith.ekstrand@collabora.com \
--cc=lina@asahilina.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=luben.tuikov@amd.com \
--cc=sumit.semwal@linaro.org \
/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
Powered by JetHome