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@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 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();
+            }
             for &fd in &info.file_list.close_on_free {
                 let closer = match DeferredFdCloser::new(GFP_KERNEL) {
                     Ok(closer) => closer,

-- 
2.53.0.473.g4a7958ca14-goog

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@google.com>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  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,

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@google.com>
> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > ---
> >  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