From: Alice Ryhl <aliceryhl@google.com>
To: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Carlos Llamas" <cmllamas@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>
Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
Alice Ryhl <aliceryhl@google.com>, Jann Horn <jannh@google.com>
Subject: [PATCH v3 4/4] rust_binder: check current before closing fds
Date: Tue, 24 Mar 2026 20:02:38 +0000 [thread overview]
Message-ID: <20260324-close-fd-check-current-v3-4-b94274bedac7@google.com> (raw)
In-Reply-To: <20260324-close-fd-check-current-v3-0-b94274bedac7@google.com>
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.
Note that on process exit, the == comparison may actually fail because
it's called from a kthread. The fd closing code is a no-op on kthreads,
so there is no actual behavior different though.
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
drivers/android/binder/allocation.rs | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/android/binder/allocation.rs b/drivers/android/binder/allocation.rs
index 7f65a9c3a0e5..691e4af5c1d0 100644
--- a/drivers/android/binder/allocation.rs
+++ b/drivers/android/binder/allocation.rs
@@ -260,19 +260,22 @@ fn drop(&mut self) {
}
}
- for &fd in &info.file_list.close_on_free {
- let closer = match DeferredFdCloser::new(GFP_KERNEL) {
- Ok(closer) => closer,
- Err(kernel::alloc::AllocError) => {
- // Ignore allocation failures.
- break;
- }
- };
-
- // Here, we ignore errors. The operation can fail if the fd is not valid, or if the
- // method is called from a kthread. However, this is always called from a syscall,
- // so the latter case cannot happen, and we don't care about the first case.
- let _ = closer.close_fd(fd);
+ if self.process.task == kernel::current!().group_leader() {
+ for &fd in &info.file_list.close_on_free {
+ let closer = match DeferredFdCloser::new(GFP_KERNEL) {
+ Ok(closer) => closer,
+ Err(kernel::alloc::AllocError) => {
+ // Ignore allocation failures.
+ break;
+ }
+ };
+
+ // Here, we ignore errors. The operation can fail if the fd is not valid, or if
+ // the method is called from a kthread. However, this is always called from a
+ // syscall, so the latter case cannot happen, and we don't care about the first
+ // case.
+ let _ = closer.close_fd(fd);
+ }
}
if info.clear_on_free {
--
2.53.0.1018.g2bb0e51243-goog
prev parent reply other threads:[~2026-03-24 20:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 20:02 [PATCH v3 0/4] " Alice Ryhl
2026-03-24 20:02 ` [PATCH v3 1/4] rust: sync: implement == operator for ARef Alice Ryhl
2026-03-24 20:02 ` [PATCH v3 2/4] rust: task: implement == operator for Task Alice Ryhl
2026-03-24 20:02 ` [PATCH v3 3/4] rust_binder: make use of == " Alice Ryhl
2026-03-24 20:02 ` Alice Ryhl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260324-close-fd-check-current-v3-4-b94274bedac7@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=cmllamas@google.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®