From nobody Sun Apr 5 18:19:08 2026 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A1772ED84C for ; Tue, 24 Mar 2026 20:02:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774382573; cv=none; b=sq+Rnko8In23SEGAWHvLGIoHNSYq31hHuo+9doCIvUGAoTiNEoaVpr2psYPYXQaN6LKLkF55ltfNQ/ssu1o/nzJ3894AmwWQ8mxMf+aBdSLYGpm+rrKvajAF6uRU7thwyHKHtWZX8io3XLLB2WxzpsXRKG941D3MHI6s1RM789c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774382573; c=relaxed/simple; bh=fFN7lYugJ/QOgXO5yWuBBN6eYrZehQy1s12OfSqPlJs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=I0biCw6yrzGA75rxAHCtsZSTXNDRg4lAUAB/3RS8JFDPYdVEpQ/DNXvh9YuvvdgvQSD/l0+dX7qOlwefaf96CigZfOigcnIffq+mFC6L+9A4EajB1dEkii5lJk08JRZAaGQ4mWJJLASDyiwvFAnIZ6E9MDZaHWgbyy5JdyEQcw0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=elo8UTSF; arc=none smtp.client-ip=209.85.221.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="elo8UTSF" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-43b53023d60so3884631f8f.2 for ; Tue, 24 Mar 2026 13:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774382570; x=1774987370; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=7Bwpp1ufcceKLHFlGDegFIy1xoIkwFlNP/wIyy6koCQ=; b=elo8UTSFqb7Ho59kZoWDJQNqlbVAY4eVvsomjzFVZWroxsPNmyr0O6EzTtczJ5dy69 VBnjMHzZ6EKk8CXh8w5BENt/+Vt5HxL0Wz9oFCjHMHFN+PTBiuIgG2QKSBOc49ILZdfc KQxsUvoJTsWVGx8fWRujOsywa0geufc4XK/xKu/uiPuHkL8/rIVWcMNoWYI6gu7fTRz7 5kySQnps3VDm42ePasYANwxoz6AxpX+EamwXGd+KwT72mxHOFmYrKARMok14wd1UzWx6 d9LyD8kGpxd0EQWXYCh5T1/61rTIOhjVnPb5A54x/FeWKUVFpBljwGkIaFnMWF/tUuct +Hiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774382570; x=1774987370; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7Bwpp1ufcceKLHFlGDegFIy1xoIkwFlNP/wIyy6koCQ=; b=a/+Bw4P0gZKL/d9FPeDANJ8hUv0i6a4tVj4DeMSdORKa7+1XjgNUy7c6yi0nmeXUXt 8VkJOtv10lUk8T/HyWNYjhIvmWch+1mTkts0HR/0fOjeqL1M+dtEvuoU1ySeXUZDYPrx RvD5RX+PCViAuPU8tZgjJPaCPSGLHvw3GunhNrsyFQSnwaZdWETMSDKlp4F7iWHtBZWD XZ0z7siryXepRW/mvvngqGy0O49PUWit0pPACPNOxhDpkg7bngEXeeZk4WpALKZC21j3 bdnOhH5zpXxyBHs+XiBf2GlUMaCykdYM8fBoFDWQKdbVR32V4RH9CkJ9VMLnlSYfbTxZ rMhQ== X-Forwarded-Encrypted: i=1; AJvYcCVVW7ZZ4ojnWQj+7KLTCpXLF7wVAPH3uBYDLDQiTjfqTrnap6vO0BIDLvvOXGnaQpAYd+lEKrry8P5VDvQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwYX7YwF5Yg4KwDUPgx3SbaqlJ0fnE0ikk04Y7vhSXifFHPBaO6 vN9CyjEUdIpdYzaGth8ez29F12XTkuRWVLZj5PzSCeb3TuRK+rmDq8ZGuJiM65/8r99TFt04pgc 1POZWMycJCsSRUTakxA== X-Received: from wmtf12.prod.google.com ([2002:a05:600c:8b4c:b0:485:34c3:177]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:3b12:b0:485:419c:4eba with SMTP id 5b1f17b1804b1-48715fc3286mr16459705e9.1.1774382569992; Tue, 24 Mar 2026 13:02:49 -0700 (PDT) Date: Tue, 24 Mar 2026 20:02:38 +0000 In-Reply-To: <20260324-close-fd-check-current-v3-0-b94274bedac7@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260324-close-fd-check-current-v3-0-b94274bedac7@google.com> X-Developer-Key: i=aliceryhl@google.com; a=openpgp; fpr=49F6C1FAA74960F43A5B86A1EE7A392FDE96209F X-Developer-Signature: v=1; a=openpgp-sha256; l=3054; i=aliceryhl@google.com; h=from:subject:message-id; bh=fFN7lYugJ/QOgXO5yWuBBN6eYrZehQy1s12OfSqPlJs=; b=owEBbQKS/ZANAwAKAQRYvu5YxjlGAcsmYgBpwu3jLX17ugD1zE0Q7MbvgEEf8tsq/mb0xZ0J0 AJYF2+uOR2JAjMEAAEKAB0WIQSDkqKUTWQHCvFIvbIEWL7uWMY5RgUCacLt4wAKCRAEWL7uWMY5 Rq5iEACy0yQ/9DHDVHZypadhpRQLSdfzjU4/rBZzVPrdhQklr7fPTyH7BnqgukTCKJ4LoQN2Wzo z4P9mdvgfaepsWcIo8jmQBKEuxCj/y46bZHvxHHId6osa5tarFT6o8k9g/C6WqFu8Y6ZkatCOtW aW+j9dfIhaxqJZnhe9Z9EqFbsu/uBRIe9uUVP8lFuLNvuLuht7BZRYhT5Lwi6vGcoXIKcRENOXU j/P/GS0q3Js+K8Yuq0ikGuIt5FV+UkxbYnNbTaMOLeSJPt7jDdVGXEXC5uEboBa1YYsAMj5TmvP Uv9XrrZVs8ZVR1Qi5Mm3Bpykgh48CpkAbMt4epi0puirH/LZENvmAjUZnQQaaVkTvel+bBXNLj9 DWrp84QfK6OnCw7SzGfYzfyp21SELHebWpy5guaRTzsAigbm4VJm4buW88I0cWaSMkeFAWLmC0l MrtcrCGxxutuATrbx7TPNDDsQGk51EqjwVfU6eko0ayTgAsUuome1WfyJMrtg6p0smpp2XRrqHt vhqPYyILosVSJ9aQEXlRikal1NE4vTHNVd78oxsEw+OxGTQQ+sLh/sJXQpQjSBhKgBiJ4WXK2DN TcIc+4+umtNmlQPAF66zToUAp5Hx46qq4GAP/tft4GtwDuyP+d/b/prDEFQbHmkpU0Vg0qLEeTt sYLKxhaykIbnroA== X-Mailer: b4 0.14.3 Message-ID: <20260324-close-fd-check-current-v3-4-b94274bedac7@google.com> Subject: [PATCH v3 4/4] rust_binder: check current before closing fds From: Alice Ryhl To: Greg Kroah-Hartman , Carlos Llamas , Miguel Ojeda , Boqun Feng , Gary Guo , "=?utf-8?q?Bj=C3=B6rn_Roy_Baron?=" , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Alice Ryhl , Jann Horn Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 =3D=3D 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 Signed-off-by: Alice Ryhl --- 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) { } } =20 - for &fd in &info.file_list.close_on_free { - let closer =3D match DeferredFdCloser::new(GFP_KERNEL) { - Ok(closer) =3D> closer, - Err(kernel::alloc::AllocError) =3D> { - // Ignore allocation failures. - break; - } - }; - - // Here, we ignore errors. The operation can fail if the f= d is not valid, or if the - // method is called from a kthread. However, this is alway= s called from a syscall, - // so the latter case cannot happen, and we don't care abo= ut the first case. - let _ =3D closer.close_fd(fd); + if self.process.task =3D=3D kernel::current!().group_leader() { + for &fd in &info.file_list.close_on_free { + let closer =3D match DeferredFdCloser::new(GFP_KERNEL)= { + Ok(closer) =3D> closer, + Err(kernel::alloc::AllocError) =3D> { + // Ignore allocation failures. + break; + } + }; + + // Here, we ignore errors. The operation can fail if t= he 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 d= on't care about the first + // case. + let _ =3D closer.close_fd(fd); + } } =20 if info.clear_on_free { --=20 2.53.0.1018.g2bb0e51243-goog