All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lyude Paul" <lyude@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 3/5] drm/nouveau: Fix drm_driver struct/nouveau.atomic parameter handling
Date: Thu, 30 Jul 2026 20:54:17 +0000	[thread overview]
Message-ID: <20260730205417.B18681F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260730203723.1649433-4-lyude@redhat.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Embedding `drm_driver` in `struct nouveau_drm` introduces an exploitable Use-After-Free vulnerability when the device is unplugged or unbound while userspace holds open file descriptors.
--

--- Patch [3]: [PATCH v4 3/5] drm/nouveau: Fix drm_driver struct/nouveau.atomic parameter handling ---
commit 6aa4a539bc58f0cd546203fa854c1edf2120c1be
Author: Lyude Paul <lyude@redhat.com>

drm/nouveau: Fix drm_driver struct/nouveau.atomic parameter handling

This commit moves the drm_driver struct from a static global variable
into the dynamically allocated nouveau_drm structure. It also handles
conditionally enabling atomic modesetting per-device.

> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -216,6 +216,7 @@ struct nouveau_drm {
>  
>  	struct nouveau_cli client;
>  	struct drm_device *dev;
> +	struct drm_driver drm_driver;
>  
>  	struct list_head clients;

[ ... ]

> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
[ ... ]
> @@ -744,12 +741,14 @@ nouveau_drm_device_new(const struct drm_driver *drm_driver, struct device *paren
>  	if (!drm)
>  		return ERR_PTR(-ENOMEM);
>  
> +	drm->drm_driver = driver_stub;
>  	drm->nvkm = device;
>  
> -	drm->dev = drm_dev_alloc(drm_driver, parent);
> +	drm->dev = drm_dev_alloc(&drm->drm_driver, parent);

[Severity: High]
Does embedding drm_driver inside nouveau_drm create a use-after-free
risk if the device is unplugged or unbound while userspace holds an open
file descriptor?

If a user opens the DRM device node, the open file descriptor holds a
reference to the drm_device. If the device is then hot-unplugged or
unbound via sysfs, nouveau_drm_device_del() will unconditionally free
the nouveau_drm struct:

nouveau_drm_device_del()
    ...
    kfree(drm);

However, the drm_device remains alive due to the file descriptor's
reference. When the user later closes the file descriptor, the DRM core
will dereference the dangling dev->driver pointer:

drm_file_free()
    ...
    if (dev->driver->postclose)
        dev->driver->postclose(dev, file);

Could this lead to memory corruption since the drm_driver struct was
already freed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730203723.1649433-1-lyude@redhat.com?part=3

  reply	other threads:[~2026-07-30 20:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 20:36 [PATCH v4 0/5] Enable atomic modesetting by default Lyude Paul
2026-07-30 20:36 ` Lyude Paul
2026-07-30 20:36 ` [PATCH v4 1/5] drm/nouveau: Fix cleanup bug in nouveau_drm_device_new() Lyude Paul
2026-07-30 20:36   ` Lyude Paul
2026-07-30 20:45   ` sashiko-bot
2026-07-30 20:36 ` [PATCH v4 2/5] drm/nouveau: Print the nouveau.atomic parameter in nouveau_display_options() Lyude Paul
2026-07-30 20:36   ` Lyude Paul
2026-07-30 20:36 ` [PATCH v4 3/5] drm/nouveau: Fix drm_driver struct/nouveau.atomic parameter handling Lyude Paul
2026-07-30 20:36   ` Lyude Paul
2026-07-30 20:54   ` sashiko-bot [this message]
2026-07-30 20:36 ` [PATCH v4 4/5] drm/nouveau/kms: Only allow enabling atomic modesetting on nv50+ Lyude Paul
2026-07-30 20:36   ` Lyude Paul
2026-07-30 20:36 ` [PATCH v4 5/5] drm/nouveau/kms/nv50-: Enable atomic modesetting by default Lyude Paul
2026-07-30 20:36   ` Lyude Paul

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=20260730205417.B18681F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lyude@redhat.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.