Re: [PATCH v5 15/24] rust: usb: make Driver trait lifetime-parameterized

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Lifetime transmute in `drvdata_borrow` and `drvdata_obtain` violates `ForeignOwnable` safety invariants.
--

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

rust: usb: make Driver trait lifetime-parameterized

This commit adds a 'bound lifetime to the associated Data type in the USB
Driver trait. This allows driver data to capture the device bound lifetime
and store device resources directly by reference without requiring Devres.

> diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs
> index 1dbb8387b4636..7aff0c82d0afc 100644
> --- a/rust/kernel/usb.rs
> +++ b/rust/kernel/usb.rs

[ ... ]

> @@ -109,8 +109,8 @@ extern "C" fn disconnect_callback(intf: *mut bindings::usb_interface) {
>  
>          // SAFETY: disconnect_callback is only ever called after a successful call to
>          // probe_callback, hence it's guaranteed that Device::set_drvdata() has been called
> -        // and stored a Pin<KBox<T::Data>>.
> -        let data = unsafe { dev.drvdata_borrow::<T::Data>() };
> +        // and stored a Pin<KBox<T::Data<'_>>>.
> +        let data = unsafe { dev.drvdata_borrow::<T::Data<'_>>() };

[Severity: High]
Does this lifetime transmute in drvdata_borrow violate the ForeignOwnable
safety invariants?

The safety documentation for drvdata_borrow and drvdata_obtain requires
that the type T must match the exact type of the ForeignOwnable previously
stored. Because the probe callback stores the data with its local lifetime
and the disconnect callback retrieves it with a different local lifetime,
T::Data<'probe> and T::Data<'_> represent distinct types in Rust. Passing
a different type to these unsafe functions violates their documented
preconditions.

Additionally, since the Data<'bound> associated type does not guarantee
covariance, could a driver implement an invariant type (for example, using
Cell<&'bound Device>)?

While an immediate use-after-free might be hard to trigger because the C
pointer remains valid, bypassing the borrow checker and casting lifetimes
via raw pointers without covariance bounds appears to be structurally unsound.

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