Re: [PATCH v4 01/27] rust: alloc: remove `'static` bound on `ForeignOwnable`

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Removing the `'static` bound on `Box` and `Pin<Box>` implementations of `ForeignOwnable` allows safe Rust code to cause use-after-free vulnerabilities by passing short-lived references to long-lived C subsystems.
- [Low] The commit lifts the `'static` requirement from the `ForeignOwnable` trait for `Box` implementations but fails to apply it uniformly, leaving `Arc<T>` inconsistently restricted.
--

commit 3010ad31fe43876a42708e20baf90c11f6c4ba78
Author: Gary Guo <gary@garyguo.net>

rust: alloc: remove 'static bound on ForeignOwnable

The 'static bound is currently necessary because there's no
restriction on the lifetime of the GAT. Add a Self: 'a bound to
restrict possible lifetimes on Borrowed and BorrowedMut, and lift
the 'static requirement.

> diff --git a/rust/kernel/alloc/kbox.rs b/rust/kernel/alloc/kbox.rs
> index c824ed6e15233..2f8c16473c2cf 100644
> --- a/rust/kernel/alloc/kbox.rs
> +++ b/rust/kernel/alloc/kbox.rs

[ ... ]

> @@ -477,7 +477,7 @@ fn try_init<E>(init: impl Init<T, E>, flags: Flags) -> Result<Self, E>
>  
>  // SAFETY: The pointer returned by `into_foreign` comes from a well aligned
>  // pointer to `T` allocated by `A`.
> -unsafe impl<T: 'static, A> ForeignOwnable for Box<T, A>
> +unsafe impl<T, A> ForeignOwnable for Box<T, A>

[Severity: Critical]
Does removing the 'static bound here allow safe Rust code to cause use-after-free
vulnerabilities by passing short-lived references to long-lived C subsystems?

For example, GenDiskBuilder::build accepts a generic Operations type T, takes
its QueueData, and stores it in the C subsystem via ForeignOwnable::into_foreign.
Previously, the 'static bound implicitly ensured QueueData did not contain local
references.

If safe code constructs a GenDisk using a Box holding stack references, and then
that GenDisk is leaked via core::mem::forget(disk), the block device would
remain registered in C while the stack frame ends. 

When the C callback queue_rq executes asynchronously, could it dereference a
dangling pointer resulting in a use-after-free?


[Severity: Low]
This isn't a bug, but should the 'static bound on Arc<T> in rust/kernel/sync/arc.rs
also be removed for consistency?

The commit message implies lifting the 'static requirement generally, but it
appears Arc<T> still retains its explicit unsafe impl<T: 'static> ForeignOwnable
for Arc<T> implementation.

>  where
>      A: Allocator,
>  {

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