From: sashiko-bot@kernel.org
To: "Danilo Krummrich" <dakr@kernel.org>
Cc: dri-devel@lists.freedesktop.org,
"Danilo Krummrich" <dakr@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>,
ojeda@kernel.org
Subject: Re: [PATCH 3/7] rust: drm: move file_operations from gem to device
Date: Fri, 14 Aug 2026 23:22:31 +0000 [thread overview]
Message-ID: <20260814232231.D3C081F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814230923.1292966-4-dakr@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing module reference counting allows driver unload while files are open, leading to Use-After-Free
--
--- Patch [3]: [PATCH 3/7] rust: drm: move file_operations from gem to device ---
commit b811d43b7a27d7b6e1655586be106750c9eefba2
Author: Danilo Krummrich <dakr@kernel.org>
rust: drm: move file_operations from gem to device
Move the file_operations definition from drm::gem::create_fops() into
UnregisteredDevice in drm::device. This is the file_operations of the
DRM minor device, set through the drm_driver struct. It is not specific
to GEM.
> diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
> index be83287fe161d..a2940e172073a 100644
> --- a/rust/kernel/drm/device.rs
> +++ b/rust/kernel/drm/device.rs
> @@ -195,10 +195,28 @@ const fn compute_features() -> u32 {
> driver_features: Self::compute_features(),
> ioctls: T::IOCTLS.as_ptr(),
> num_ioctls: T::IOCTLS.len() as i32,
> - fops: &Self::GEM_FOPS,
> + fops: &Self::FOPS,
> };
>
> - const GEM_FOPS: bindings::file_operations = drm::gem::create_fops();
> + const FOPS: bindings::file_operations = {
> + let mut fops: bindings::file_operations = pin_init::zeroed();
> +
> + fops.owner = core::ptr::null_mut();
[Severity: High]
This is a pre-existing issue, but does setting fops.owner to null_mut()
allow the driver module to be unloaded while file descriptors remain open?
If fops.owner is null, fops_get() in drm_stub_open() won't increment the
driver module's reference count. A user could open the DRM device node,
the module could be unloaded via rmmod (unmapping its .rodata section
where FOPS resides), and subsequent ioctl or close operations would
dereference filp->f_op into unmapped memory, causing a panic.
Should this be updated to use the Rust equivalent of THIS_MODULE
instead of null_mut() to ensure VFS module reference counting works
correctly?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260814230923.1292966-1-dakr@kernel.org?part=3
next prev parent reply other threads:[~2026-08-14 23:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 23:08 [PATCH 0/7] lifetime-parameterized DRM File private data Danilo Krummrich
2026-08-14 23:08 ` [PATCH 1/7] rust: drm: rename Ioctl device context to Userspace Danilo Krummrich
2026-08-14 23:09 ` [PATCH 2/7] rust: drm: gem: gate open/close callbacks with RegistrationGuard Danilo Krummrich
2026-08-14 23:21 ` sashiko-bot
2026-08-14 23:09 ` [PATCH 3/7] rust: drm: move file_operations from gem to device Danilo Krummrich
2026-08-14 23:22 ` sashiko-bot [this message]
2026-08-14 23:09 ` [PATCH 4/7] rust: fs: add iminor() helper Danilo Krummrich
2026-08-14 23:09 ` [PATCH 5/7] rust: drm: wrap fops open with RegistrationGuard Danilo Krummrich
2026-08-14 23:29 ` sashiko-bot
2026-08-14 23:09 ` [PATCH 6/7] rust: drm: make Driver::File lifetime-parameterized Danilo Krummrich
2026-08-14 23:23 ` sashiko-bot
2026-08-14 23:09 ` [PATCH 7/7] rust: drm: return impl PinInit from DriverFile::open() Danilo Krummrich
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=20260814232231.D3C081F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=acourbot@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--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.