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

[Greg KH]

On Fri, Jan 09, 2026 at 01:44:22PM +0900, jongan.kim@xxxxxxx wrote:
> From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
> 
> > On Thu, Jan 08, 2026 at 10:10:11AM +0900, jongan.kim@xxxxxxx wrote:
> > > From: "JongAn Kim" <jongan.kim@xxxxxxx>
> > > 
> > > 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.

I don't think any of binder supports pid namespaces.  Well, maybe one
thread thing, but not the normal functionality from what I can see.

So why just focus on the freeze ioctl?  What about all of the other
ones?

> > > 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"?

> 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?  :)

thanks,

greg k-h