From: sashiko-bot@kernel.org
To: oushixiong1025@163.com
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: reset dev->registered on drm_dev_register() error path
Date: Thu, 06 Aug 2026 09:43:03 +0000 [thread overview]
Message-ID: <20260806094304.5196F1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260806093315.594335-1-oushixiong1025@163.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Userspace can open the DRM minor device before probe completes, leading to UAF if probe fails.
--
--- Patch [1]: [PATCH] drm: reset dev->registered on drm_dev_register() error path ---
commit 4863f2824dd190d908ed2dadca48efc26b615e3b
Author: Shixiong Ou <oushixiong@kylinos.cn>
drm: reset dev->registered on drm_dev_register() error path
This commit ensures dev->registered is reset to false on the error path
in drm_dev_register(). This prevents a spurious WARN_ON during teardown
of drmm-managed resources after a failed probe.
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 1ff0bf7cba6aa..4497af8c9d1c6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -1120,6 +1120,7 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
> if (dev->driver->unload)
> dev->driver->unload(dev);
> err_minors:
> + dev->registered = false;
[Severity: High]
This isn't a bug introduced by this patch, but while looking at the error
path here, can userspace open the DRM minor device before probe completes and
trigger a use-after-free if probe fails?
In drm_dev_register(), the device node is exposed to userspace early:
drm_dev_register() {
...
ret = drm_minor_register(dev, DRM_MINOR_PRIMARY);
...
}
If a subsequent step fails (like drm_modeset_register_all), we unwind here,
but what happens if userspace already opened the device?
The drm_device refcount prevents the structure from being freed, but the
driver probe returns an error, triggering devres cleanup of MMIO and
driver-private data.
Because the DRM core doesn't set dev->unplugged = true on this path, and
drm_ioctl() doesn't check dev->registered:
drm_ioctl() {
if (drm_dev_is_unplugged(dev))
return -ENODEV;
...
}
Does this allow userspace to continue issuing ioctls to the torn-down
hardware?
> remove_compat_control_link(dev);
> drm_minor_unregister(dev, DRM_MINOR_ACCEL);
> drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260806093315.594335-1-oushixiong1025@163.com?part=1
prev parent reply other threads:[~2026-08-06 9:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 9:33 [PATCH] drm: reset dev->registered on drm_dev_register() error path oushixiong1025
2026-08-06 9:43 ` 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=20260806094304.5196F1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=oushixiong1025@163.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.