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: <2026010828-squash-tranquil-7544@gregkh> (raw)
Date: Fri,  9 Jan 2026 13:44:22 +0900
From: jongan.kim@....com
To: gregkh@...uxfoundation.org,
	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

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.

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