linux-kernel - Re: [PATCH RESEND] binder: handle PID namespace conversion for freeze operation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20260115080619.317006-1-jongan.kim@lge.com>
Date: Thu, 15 Jan 2026 17:06:19 +0900
From: jongan.kim@....com
To: gregkh@...uxfoundation.org
Cc: aliceryhl@...gle.com,
	arve@...roid.com,
	brauner@...nel.org,
	cmllamas@...gle.com,
	ht.hong@....com,
	jongan.kim@....com,
	jungsu.hwang@....com,
	kernel-team@...roid.com,
	linux-kernel@...r.kernel.org,
	sanghun.lee@....com,
	seulgi.lee@....com,
	sunghoon.kim@....com,
	tkjos@...roid.com,
	heesu0025.kim@....com
Subject: Re: [PATCH RESEND] binder: handle PID namespace conversion for freeze operation

> 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@....com wrote:
> > > From: Greg KH <gregkh@...uxfoundation.org>
> > > 
> > > > On Thu, Jan 08, 2026 at 10:10:11AM +0900, jongan.kim@....com wrote:
> > > > > From: "JongAn Kim" <jongan.kim@....com>
> > > > > 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