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] [day] [month] [year] [list]

Message-ID: <aWC-tgBQD9Lwn3Lu@google.com>
Date: Fri, 9 Jan 2026 08:39:18 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: jongan.kim@....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 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.

Alice