Re: [PATCH v3 16/27] rust: types: add `ForLt` trait for higher-ranked lifetime support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Safe Rust code can directly name and use `UnsafeForLtImpl` to bypass covariance proofs, leading to use-after-free.
- [High] The `ForLt!` macro fails to check covariance for types wrapped in macro invocations.
- [Low] The `cast_ref` function is incorrectly annotated with `#[inline(always)]`.
--

commit 2088fc9ea2c7348deada4ab3dfcc55a6783dcf27
Author: Gary Guo <gary@garyguo.net>

rust: types: add ForLt trait for higher-ranked lifetime support

This commit adds a ForLt trait and macro to support types that are generic
over a lifetime, ensuring covariance for safe lifetime shortening. It
provides a way to represent types that are themselves generic over
lifetimes, which is useful for cross-referencing data.

Link: https://docs.rs/higher-kinded-types/ [1]

> diff --git a/rust/kernel/types/for_lt.rs b/rust/kernel/types/for_lt.rs
> new file mode 100644
> index 0000000000000..22b4518a115b3
> --- /dev/null
> +++ b/rust/kernel/types/for_lt.rs
[ ... ]
> +    /// Cast a reference to a shorter lifetime.
> +    #[inline(always)]
> +    fn cast_ref<'r, 'short: 'r, 'long: 'short>(long: &'r Self::Of<'long>) -> &'r Self::Of<'short> {
> +        // SAFETY: This is sound as this trait guarantees covariance.
> +        unsafe { core::mem::transmute(long) }
> +    }
> +}

Should this function use #[inline] instead of #[inline(always)]?

According to the Rust coding guidelines, #[inline(always)] is reserved for
functions using build_assert!() that depend on function parameters. For small
forwarding abstractions like this, #[inline] should be used.

[ ... ]
> +/// `N` is to provide the macro a place to emit arbitrary items, in case it needs to prove
> +/// additional properties.
> +#[doc(hidden)]
> +pub struct UnsafeForLtImpl<T: ?Sized, WF, const N: usize>(PhantomData<(WF, T)>);
> +
> +// This is a helper trait for implementation `ForLt` to be able to use HRTB.
> +#[doc(hidden)]
> +pub trait WithLt<'a> {
> +    type Of: 'a;
> +}
> +
> +// SAFETY: In `ForLt!` macro, a covariance proof is generated when naming `UnsafeForLtImpl`
> +// and it will fail to evaluate if the type is not covariant.
> +unsafe impl<T: ?Sized + for<'a> WithLt<'a>, WF> ForLt for UnsafeForLtImpl<T, WF, 0> {

Does this allow safe Rust code to bypass covariance proofs?

Because UnsafeForLtImpl is a public type, it appears safe code can name it
directly to safely obtain a ForLt implementation for a contravariant or
invariant type. For example:

    UnsafeForLtImpl<dyn for<'a> WithLt<'a, Of = fn(&'a ())>, fn(&'static ()), 0>

This would bypass the compiler variance checks generated by the macro's
anonymous const block, potentially enabling use-after-free vulnerabilities
from safe code via cast_ref.

> diff --git a/rust/macros/for_lt.rs b/rust/macros/for_lt.rs
> new file mode 100644
> index 0000000000000..df2027789713a
> --- /dev/null
> +++ b/rust/macros/for_lt.rs
[ ... ]
> +            // `&[mut] T` is covariant over lifetime.
> +            // In case we have `&[mut] NoLifetime`, we don't need to do additional checks.
> +            Type::Reference(ty) if !ty.elem.has_lifetime(self.0) => (),
> +
> +            // No mention of lifetime at all, no need to perform compiler check.
> +            ty if !ty.has_lifetime(self.0) => (),

Can this logic fail to check covariance for types wrapped in macro invocations?

The syntactic prover uses has_lifetime to determine if a type depends on the
generic lifetime binder. However, the underlying syn visitor does not traverse
into the unparsed TokenStream of a macro invocation.

If a user provides a type wrapped in a macro, such as
ForLt!(for<'a> SomeMacro!(fn(&'a u32))), has_lifetime will return false.

This would cause the macro to silently skip generating the prove_covariant
safety checks, which might allow unsound lifetime downcasting on contravariant
types.

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