Re: [PATCH v5 16/24] rust: i2c: 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] Adding a `'bound` lifetime parameter to the driver's `Data` associated type causes unsound lifetime transmutation during driver lifecycle callbacks, leading to potential use-after-free vulnerabilities.
--

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

rust: i2c: make Driver trait lifetime-parameterized

This commit adds a 'bound lifetime to the associated Data type in the I2C
Driver trait. This allows the bus device private data to store references
to device resources directly instead of requiring Devres.

> diff --git a/rust/kernel/i2c.rs b/rust/kernel/i2c.rs
> index 50feade0fb58c..6094d32652e38 100644
> --- a/rust/kernel/i2c.rs
> +++ b/rust/kernel/i2c.rs
[ ... ]
> @@ -176,8 +176,8 @@ extern "C" fn remove_callback(idev: *mut bindings::i2c_client) {
>  
>          // SAFETY: `remove_callback` is only ever called after a successful call to
>          // `probe_callback`, hence it's guaranteed that `I2cClient::set_drvdata()` has been called
> -        // and stored a `Pin<KBox<T::Data>>`.
> -        let data = unsafe { idev.as_ref().drvdata_borrow::<T::Data>() };
> +        // and stored a `Pin<KBox<T::Data<'_>>>`.
> +        let data = unsafe { idev.as_ref().drvdata_borrow::<T::Data<'_>>() };

[Severity: High]
Does this type inference violate the safety contract of drvdata_borrow()?

During probe(), the data is stored with the lifetime of the probe call's
reference to idev, creating a T::Data<'probe>. However, here in
remove_callback(), drvdata_borrow::<T::Data<'_>>() infers a new lifetime
based on the local remove_callback() reference, resulting in
T::Data<'remove>.

Since drvdata_borrow() requires the types to match exactly, changing the
inferred lifetime seems to cause an unsound transmutation. If T::Data<'bound>
is invariant over the lifetime (for example, if it contains a Mutex holding
an Option<&'bound I2cClient>), could safe Rust driver code stash the short
lived 'remove reference inside the Data struct during unbind?

When remove_callback() returns, the 'remove reference would be invalidated.
If the driver data is subsequently dropped later on, could the Drop
implementation read the stashed, now-dangling reference and cause a
use-after-free?

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