Re: [PATCH v2 4/4] rust_binder: check current before closing fds

[Gary Guo]

On Fri Feb 27, 2026 at 9:34 AM GMT, Alice Ryhl wrote:
> This list gets populated once the transaction is delivered to the target
> process, at which point it's not touched again except in BC_FREE_BUFFER
> and process exit, so if the list has been populated then this code
> should not run in the context of the wrong userspace process.
>
> However, why tempt fate? The function itself can run in the context of
> both the sender and receiver, and if someone can engineer a scenario
> where it runs in the sender and this list is non-empty (or future Rust
> Binder changes make such a scenario possible), then that'd be a problem
> because we'd be closing random unrelated fds in the wrong process.
>
> Suggested-by: Jann Horn <jannh@xxxxxxxxxx>
> Signed-off-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>
> ---
>  drivers/android/binder/allocation.rs | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/android/binder/allocation.rs b/drivers/android/binder/allocation.rs
> index 7f65a9c3a0e5..31a42738a99d 100644
> --- a/drivers/android/binder/allocation.rs
> +++ b/drivers/android/binder/allocation.rs
> @@ -260,6 +260,10 @@ fn drop(&mut self) {
>                  }
>              }
>  
> +            if self.process.task != kernel::current!().group_leader() {
> +                // Called from wrong task, so do not free fds.
> +                info.file_list.close_on_free.clear();
> +            }

If you're sure that this won't actually happen, perhaps print a warning if it's
called from a different task but the list is not empty?

Also, I think this can be

if ... {
    for &fd in ... {
    }
}

rather than `.clear()` and then iterate.

Best,
Gary

>              for &fd in &info.file_list.close_on_free {
>                  let closer = match DeferredFdCloser::new(GFP_KERNEL) {
>                      Ok(closer) => closer,