Re: [PATCH v5 01/19] rust: drm: ioctl: fix unbounded lifetimes in ioctl handler arguments

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The `declare_drm_ioctls!` macro is unsound because it allows type inference to dictate the generic `Driver` type for `Device` and `File`, enabling potential cross-type downcasts (type confusion).
--

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

rust: drm: ioctl: fix unbounded lifetimes in ioctl handler arguments

This commit fixes unbounded lifetimes created by unsafe pointer dereferences
in the declare_drm_ioctls! macro. It introduces a higher-ranked function
pointer coercion to ensure that handlers accept universally quantified
lifetimes, preventing them from improperly demanding static references.

Closes: https://lore.kernel.org/all/20260620011346.A47D01F000E9@smtp.kernel.org/

> diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> index cf328101dde4e..ccf4150d83b69 100644
> --- a/rust/kernel/drm/ioctl.rs
> +++ b/rust/kernel/drm/ioctl.rs
> @@ -135,6 +135,12 @@ macro_rules! declare_drm_ioctls {
>                              // dev/file match the current driver these ioctls are being declared
>                              // for, and it's not clear how to enforce this within the type system.
>                              let dev = $crate::drm::device::Device::from_raw(raw_dev);

[Severity: High]
This is a pre-existing issue, but does this instantiation of
Device::from_raw() leave the generic driver type parameter unbounded?

Since type inference can dictate the generic driver type for the device based
on the handler's signature, is it possible for a handler expecting
&Device<DriverB> to be passed for an IOCTL declared in DriverA?

If that happens, type inference might instantiate Device::from_raw<DriverB>.
The DRM core would later pass a DriverA device, but the safe handler might
access it assuming DriverB's layout, potentially causing type confusion.

Is there a way to strictly bind the driver type in the macro so we prevent
potential cross-type downcasts?

> +
> +                            // Enforce that the handler accepts higher-ranked
> +                            // lifetimes, preventing it from requiring 'static
> +                            // references that could escape this scope.
> +                            let _: for<'a> fn(&'a _, &'a mut _, &'a _) -> _ = $func;
> +
>                              // SAFETY: The ioctl argument has size `_IOC_SIZE(cmd)`, which we
>                              // asserted above matches the size of this type, and all bit patterns of
>                              // UAPI structs must be valid.

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