From: sashiko-bot@kernel.org
To: "Jonghyuk Kim(MalHyuk)" <malhyuk97@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/nouveau: RCU-free the scheduler-containing nouveau_sched
Date: Wed, 02 Sep 2026 01:39:51 +0000 [thread overview]
Message-ID: <20260902013952.624C61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902012717.880724-1-malhyuk97@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Use-After-Free (Incomplete Fix)
--
commit a4cb3c10462917197ec6f8cdfe7a265ad10ef18a
Author: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
drm/nouveau: RCU-free the scheduler-containing nouveau_sched
This commit attempts to fix a use-after-free issue by deferring the freeing
of the scheduler object to an RCU callback.
> diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c b/drivers/gpu/drm/nouveau/nouveau_sched.c
> index 8b9f935afe094..b3f02c490ecb6 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_sched.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_sched.c
> @@ -517,7 +517,7 @@ nouveau_sched_destroy(struct nouveau_sched **psched)
> struct nouveau_sched *sched = *psched;
>
> nouveau_sched_fini(sched);
> - kfree(sched);
> + kfree_rcu(sched, rcu);
[Severity: High]
This isn't a bug introduced by this patch, but does this actually fix the
underlying use-after-free issue?
Using kfree_rcu() only defers freeing the scheduler by a single RCU grace
period. However, dma_fence objects exported to userspace (e.g., via
sync_file) can outlive this grace period since userspace controls the file
descriptor lifetime.
When userspace eventually queries the fence info, sync_fill_fence_info()
acquires a new rcu_read_lock() and calls dma_fence_timeline_name(), which
invokes drm_sched_fence_get_timeline_name():
drivers/gpu/drm/scheduler/sched_fence.c:drm_sched_fence_get_timeline_name() {
...
return (const char *)fence->sched->name;
}
Because the nouveau_sched memory is physically freed after the initial RCU
grace period elapses, this new RCU read-side critical section does not
protect it. Won't this unconditionally dereference fence->sched->name on
the already-freed memory, resulting in the exact same use-after-free read
this patch intends to fix?
>
> *psched = NULL;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902012717.880724-1-malhyuk97@gmail.com?part=1
prev parent reply other threads:[~2026-09-02 1:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 1:27 [PATCH] drm/nouveau: RCU-free the scheduler-containing nouveau_sched Jonghyuk Kim(MalHyuk)
2026-09-02 1:39 ` sashiko-bot [this message]
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=20260902013952.624C61F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=malhyuk97@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.