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

[Alice Ryhl <aliceryhl@google.com>]

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

Alice