Re: [PATCH v5 07/19] rust: drm: restrict AlwaysRefCounted to Normal GEM Object context

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Type confusion leading to out-of-bounds memory access due to C-allocated GEM objects being unsafely cast to Rust `Object<T>`.
--

commit c0b1cc771ed0a5a11fb0a16d94befa79e5c52a6d
Author: Danilo Krummrich <dakr@kernel.org>

rust: drm: restrict AlwaysRefCounted to Normal GEM Object context

This commit restricts AlwaysRefCounted for gem::Object and
gem::shmem::Object to the Normal context. It updates Object::new methods
to Normal-only blocks and simplifies DeviceContext usage.

> diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
> index 1023ddccd7857..d56cbe2663e29 100644
> --- a/rust/kernel/drm/gem/mod.rs
> +++ b/rust/kernel/drm/gem/mod.rs
[ ... ]
> @@ -198,8 +196,8 @@ fn create_handle<D, F>(&self, file: &drm::File<F>) -> Result<u32>
>      /// Looks up an object by its handle for a given File.
>      fn lookup_handle<D, F>(file: &drm::File<F>, handle: u32) -> Result<ARef<Self>>
>      where
> -        Self: AllocImpl<Driver = D>,
> -        D: drm::Driver<Object<Normal> = Self, File = F>,
> +        Self: AllocImpl<Driver = D> + AlwaysRefCounted,
> +        D: drm::Driver<Object = Self, File = F>,
>          F: drm::file::DriverFile<Driver = D>,
>      {
>          // SAFETY: The arguments are all valid per the type invariants.

[Severity: High]
This is a pre-existing issue, but can this lead to an out-of-bounds memory
access during type casting?

In rust/kernel/drm/gem/shmem.rs, ALLOC_OPS leaves gem_create_object as None.
When userspace creates a dumb buffer or imports a PRIME buffer, the C helpers
drm_gem_shmem_dumb_create() and drm_gem_shmem_prime_import_sg_table() fall 
back to allocating a bare C struct drm_gem_shmem_object via kzalloc().

When the driver later calls lookup_handle() (defined here in 
rust/kernel/drm/gem/mod.rs), the underlying code unsafely casts the raw
C object pointer to the Rust wrapper:

    let obj = unsafe { Self::from_raw(ptr) };

Since the C-allocated object lacks the trailing fields of the Rust Object
wrapper (such as inner and sgt_lock), would accessing those fields read or
write out of bounds? Is there a need to provide a gem_create_object callback
so the full Rust wrapper is always allocated?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628145406.2107056-1-dakr@kernel.org?part=7