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

[Alice Ryhl]

On Fri, Feb 27, 2026 at 12:28:04PM +0000, Gary Guo wrote:
> 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.

Actually, I guess there is one case. When the binder fd is closed, this
code may run from deferred_release() in workqueue context. Now, the fd
close logic is a no-op from workqueue context, so this patch still
doesn't change behavior, but it means the fds wont get closed.

That said, this actually matches C Binder behavior. It also does not
close BINDER_TYPE_FDA fds when you close the Binder fd without first
issuing the cleanup command for each live BINDER_TYPE_FDA object.
Probably not intentional, though.

Alice