From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lgeamrelo11.lge.com (lgeamrelo11.lge.com [156.147.23.51]) (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 965D3283C87 for ; Thu, 15 Jan 2026 08:06:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.147.23.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768464393; cv=none; b=NjvikkECK4p/IqBzsxHBtZzFOj+6KEQenf09cBuJ0K/UItpZAYhhLW80XBNc1Zt1IkWlESQMqXwJapjI7eFv38UfD/ViInJi4+axfbvWnqmNP9Kj/cuLe8t/KmznkAWthJvFVu8NRu+20E86GatXZi0mq8qtc98pQ77MFD2K5i8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768464393; c=relaxed/simple; bh=HZHhJWDapRmCpSLnyEUgS3rrP0rQ27au755Av06t0/0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=aFR3qO2HcEQJAKYTRVH/D12qMgbQKJOLql2pBMDkVEThhGV3us3r/g37zPWgeGJrpA3IRsXV47DS6YYaS7pQDcRJfTqYW8lqxQ6yRUKPA0Sm4Kl5FKv1xtq0f+/ByoZVF659WA0nAxYUhUrACfWqLnXU1ABLN+HaDWqXLeOBNUc= 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.51 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.51 with ESMTP; 15 Jan 2026 17:06:20 +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.15) by 156.147.1.127 with ESMTP; 15 Jan 2026 17:06:20 +0900 X-Original-SENDERIP: 10.159.44.15 X-Original-MAILFROM: jongan.kim@lge.com From: jongan.kim@lge.com To: gregkh@linuxfoundation.org Cc: aliceryhl@google.com, arve@android.com, brauner@kernel.org, cmllamas@google.com, ht.hong@lge.com, jongan.kim@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, heesu0025.kim@lge.com Subject: Re: [PATCH RESEND] binder: handle PID namespace conversion for freeze operation Date: Thu, 15 Jan 2026 17:06:19 +0900 Message-Id: <20260115080619.317006-1-jongan.kim@lge.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > On Fri, Jan 09, 2026 at 08:50:01AM +0100, Greg KH wrote: > > On Fri, Jan 09, 2026 at 01:44:22PM +0900, jongan.kim@lge.com wrote: > > > From: Greg KH > > > > > > > On Thu, Jan 08, 2026 at 10:10:11AM +0900, jongan.kim@lge.com wrote: > > > > > From: "JongAn Kim" > > > > > 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.) > > > > Are you sure? Those pids come from userspace, how can they be "global"? > > I guess the BINDER_FREEZE/BINDER_GET_FROZEN_INFO ioctls are the only > that takes a pid as *input*. All other pid uses in Binder are outputs. > > > > 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. > > > > So you are relying on the registration in the global namespace, but what > > about the others? I see a lot of "raw" pids happening in the binder > > code, it's odd that this would only be an issue in that one ioctl. > > > > And, I hate to ask, what about the rust version of binder in the tree > > now? What does that do? :) > > Both drivers handle the BINDER_FREEZE ioctl in the same way. The freeze > operation takes a target pid to freeze as input, and loops through all > open Binder fds/binder_procs and picks out any procs for which the > target pid is equal to `task->group_leader->pid`, with `task` being the > task that originally opened said fd. Then those fds/binder_procs are > marked frozen meaning that new incoming transactions are rejected. As Alice mentioned, since only the freeze operation takes a pid as input, it receives the local pid of the namespace. This patch converts this pid to the global pid of the init namespace for matching pid of binder_procs properly. (binder_procs has `task->group_leader->pid`). Are there any concerns or problems for this logic? Thanks. // JongAn, Kim