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: <2026010941-carwash-disabled-c713@gregkh>
Date: Fri, 9 Jan 2026 08:50:01 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: jongan.kim@....com
Cc: aliceryhl@...gle.com, arve@...roid.com, brauner@...nel.org,
	cmllamas@...gle.com, ht.hong@....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
Subject: Re: [PATCH RESEND] binder: handle PID namespace conversion for
 freeze operation

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