From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 875BF32692B for ; Thu, 8 Jan 2026 05:37:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767850678; cv=none; b=Q5KqQT2yhEEWvMrfRDPv5wsovI1OglSdD6s6mlSGggmli/jQG276qb2jINIV9cq6Fc1PX04dRMUyO7xVJvIow63iM3fibjdYiqYl875vi2dgCAS5rXlwGMWPDdSrUP4g477HWnpARujdnVD+DGivjO7kJZcIU8qCaQ/BFvCjf8c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767850678; c=relaxed/simple; bh=OR3ovrmb4YYSiVXZW+j/KZEXYydFTdrQ61OibmW5W3s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PWb//zhkSu1harj8bP30GNDsRVcImCf5cFCdHOhmHR9EesP4YT0fDV8AocqZfIzIwq/NptpK6kEfq/tDVYRBRwJUzMlX60RaUo9EQTC88n4utcNZYVNc7pLS8aNbpyC7NDrToy6P6jA5ZINOffL4q6sB7k2l8RHS8866NLTGDtk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=oyXKyBmt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="oyXKyBmt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F2A6C116C6; Thu, 8 Jan 2026 05:37:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1767850677; bh=OR3ovrmb4YYSiVXZW+j/KZEXYydFTdrQ61OibmW5W3s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oyXKyBmtlFEjvdx8P3sF9dxQRG1/qLgeHWzJ5vNW9C1eikbuEbjfepMqtv2ffQ8ga oqY4BXl0dRd4KQ4oe12A2DmSSmD0FaVSQKUYVS0K9Q1UQvL52DFqqFXfyVR2FiImNi KDVZDeuQnBvSvQ/x3ZcGjVkqH1esQKKsXBdVQRSE= Date: Thu, 8 Jan 2026 06:37:53 +0100 From: Greg KH To: jongan.kim@lge.com Cc: arve@android.com, tkjos@android.com, brauner@kernel.org, cmllamas@google.com, aliceryhl@google.com, linux-kernel@vger.kernel.org, kernel-team@android.com, ht.hong@lge.com, sunghoon.kim@lge.com, sanghun.lee@lge.com, jungsu.hwang@lge.com, seulgi.lee@lge.com Subject: Re: [PATCH RESEND] binder: handle PID namespace conversion for freeze operation Message-ID: <2026010828-squash-tranquil-7544@gregkh> References: <20251203024140.175952-1-jongan.kim@lge.com> <20260108011011.450202-1-jongan.kim@lge.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260108011011.450202-1-jongan.kim@lge.com> On Thu, Jan 08, 2026 at 10:10:11AM +0900, jongan.kim@lge.com wrote: > From: "JongAn Kim" > > Currently, when a freeze is attempted from a non-init PID namespace, > there is a possibility that the wrong process in the init namespace > may be frozen due to PID collision across namespaces. I did not think that binder worked with pid namespaces. I think I've asked this before and was told it was not supported. So how are you running into this? What system requires this? > For example, if a container with PID namespace has a process with > PID 100 (which maps to PID 5000 in init namespace), attempting to > freeze PID 100 from the container could incorrectly match a different > process with PID 100 in the init namespace. > > This patch fixes the issue by: > 1. Converting the caller's PID from their namespace to init namespace > 2. Matching against binder_proc->pid (which stores init namespace TGID) > 3. Returning -EINVAL for invalid PIDs and -ESRCH for not-found processes Are you sure this is the only place pid namespaces come into play in binder? If this is going to be supported, I think all uses of pids need to handle namespaces. or am I confused as to what is broken here? thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lgeamrelo13.lge.com (lgeamrelo13.lge.com [156.147.23.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25A4A2E8DE3 for ; Fri, 9 Jan 2026 04:45:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.147.23.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767933918; cv=none; b=NQyciHqXgChymelKn7LtzEj8sXBv92UHap9MFqQfHRVD0zJCI1iboXFNVq/RPbhSIYsRxwGgg+ikM/hCi2IDvRoB1paZ88tpiwjNe7JwoZz2mcFrOyNepyXwMWARktic7FdMgGRpHjVcJHVtKY9fETmwyKQXDfcGeThgZTb8R5g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767933918; c=relaxed/simple; bh=6wNI8etZzev0FYHK1KGPe3OstN8yKx2Raxh8d5cKSC8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=Dnw84xMec09W82c8AlfrmguR+JNbz/N8LOyKg2q0fJsXB1A9nahO/XWqh7ALUmw8k4b+e4VLsmxmooXPNfV3iA2yhlNbFDHkxIXdLDKm5XE/50ZrFmE0ZIiQFdT6t0dYAIzBqN8BH/YG1r/Jz0PxvrHAQUXB8bYX2xA4o6lj4lY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lge.com; spf=pass smtp.mailfrom=lge.com; arc=none smtp.client-ip=156.147.23.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lge.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lge.com Received: from unknown (HELO lgeamrelo04.lge.com) (156.147.1.127) by 156.147.23.53 with ESMTP; 9 Jan 2026 13:45:01 +0900 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: jongan.kim@lge.com Received: from unknown (HELO jongan-kim-nissan-cdc.bee-live.svc.cluster.local) (10.159.44.41) by 156.147.1.127 with ESMTP; 9 Jan 2026 13:45:01 +0900 X-Original-SENDERIP: 10.159.44.41 X-Original-MAILFROM: jongan.kim@lge.com From: jongan.kim@lge.com To: gregkh@linuxfoundation.org, jongan.kim@lge.com Cc: aliceryhl@google.com, arve@android.com, brauner@kernel.org, cmllamas@google.com, ht.hong@lge.com, jungsu.hwang@lge.com, kernel-team@android.com, linux-kernel@vger.kernel.org, sanghun.lee@lge.com, seulgi.lee@lge.com, sunghoon.kim@lge.com, tkjos@android.com Subject: Re: [PATCH RESEND] binder: handle PID namespace conversion for freeze operation Date: Fri, 9 Jan 2026 13:44:22 +0900 Message-ID: <2026010828-squash-tranquil-7544@gregkh> (raw) X-Mailer: git-send-email 2.25.1 In-Reply-To: <20260108011011.450202-1-jongan.kim@lge.com> References: <2026010828-squash-tranquil-7544@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: <20260109044422.1SNA7_LXu0GVzQU7aSw9g05ifS8KV0BZ4fgLWRvEUUA@z> From: Greg KH > On Thu, Jan 08, 2026 at 10:10:11AM +0900, jongan.kim@lge.com wrote: > > From: "JongAn Kim" > > > > Currently, when a freeze is attempted from a non-init PID namespace, > > there is a possibility that the wrong process in the init namespace > > may be frozen due to PID collision across namespaces. > > I did not think that binder worked with pid namespaces. I think I've > asked this before and was told it was not supported. > > So how are you running into this? What system requires this? Thank you for your feedback. We isolated the pid namespace in order to run the legacy system within Android Automotive. Upon contacting Google, we were informed that the binder’s freeze operation currently does not support the pid namespace. They also mentioned that once this binder freeze problem is resolved, we can use pid namespace with android GKI. > > For example, if a container with PID namespace has a process with > > PID 100 (which maps to PID 5000 in init namespace), attempting to > > freeze PID 100 from the container could incorrectly match a different > > process with PID 100 in the init namespace. > > > > This patch fixes the issue by: > > 1. Converting the caller's PID from their namespace to init namespace > > 2. Matching against binder_proc->pid (which stores init namespace TGID) > > 3. Returning -EINVAL for invalid PIDs and -ESRCH for not-found processes > > Are you sure this is the only place pid namespaces come into play in > binder? If this is going to be supported, I think all uses of pids need > to handle namespaces. > > or am I confused as to what is broken here? > > thanks, > > greg k-h As far as we've confirmed, only the binder’s freeze ioctl operation receives and processes a pid from user space. (other binder operation except freeze handles pid as global pid in kernel space.) Since binder_open() registers the pid to binder_procs based on the global pid of the init namespace, the freeze operation does not function correctly when executed within a separate namespace. Moreover, in cases where duplicate pid exist, there is a potential risk of freezing an unintended process in the init namespace. Thanks. // JongAn, Kim