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

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

[jongan.kim]

From: "JongAn Kim" <jongan.kim@lge.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.

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

This change ensures correct PID handling when binder freeze occurs in
non-init PID namespace.

Signed-off-by: JongAn Kim <jongan.kim@lge.com>
---
 drivers/android/binder.c | 52 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a3a1b5c33ba3..337d1f2c4533 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -5607,6 +5607,40 @@ static bool binder_txns_pending_ilocked(struct binder_proc *proc)
 	return false;
 }
 
+/**
+ * binder_convert_to_init_ns_tgid() - Convert pid to global pid(init namespace)
+ * @pid:    pid from user space
+ *
+ * Converts a process ID (TGID) from the caller's PID namespace to the
+ * corresponding TGID in the init namespace.
+ *
+ * Return: On success, returns TGID in init namespace (positive value).
+ *         On error, returns -EINVAL if pid <= 0, or -ESRCH if process
+ *         not found or not visible in init namespace.
+ */
+static int binder_convert_to_init_ns_tgid(int pid)
+{
+	struct task_struct *task;
+	int init_ns_pid;
+
+	/* already in init namespace */
+	if (task_is_in_init_pid_ns(current))
+		return pid;
+
+	if (pid <= 0)
+		return -EINVAL;
+
+	rcu_read_lock();
+	task = pid_task(find_vpid(pid), PIDTYPE_PID);
+	init_ns_pid = task ? task_tgid_nr_ns(task, &init_pid_ns) : -ESRCH;
+	rcu_read_unlock();
+
+	if (!init_ns_pid)
+		return -ESRCH;
+
+	return init_ns_pid;
+}
+
 static void binder_add_freeze_work(struct binder_proc *proc, bool is_frozen)
 {
 	struct binder_node *prev = NULL;
@@ -5715,13 +5749,18 @@ static int binder_ioctl_get_freezer_info(
 	struct binder_proc *target_proc;
 	bool found = false;
 	__u32 txns_pending;
+	int init_ns_pid = 0;
 
 	info->sync_recv = 0;
 	info->async_recv = 0;
 
+	init_ns_pid = binder_convert_to_init_ns_tgid(info->pid);
+	if (init_ns_pid < 0)
+		return init_ns_pid;
+
 	mutex_lock(&binder_procs_lock);
 	hlist_for_each_entry(target_proc, &binder_procs, proc_node) {
-		if (target_proc->pid == info->pid) {
+		if (target_proc->pid == init_ns_pid) {
 			found = true;
 			binder_inner_proc_lock(target_proc);
 			txns_pending = binder_txns_pending_ilocked(target_proc);
@@ -5867,6 +5906,7 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 		struct binder_freeze_info info;
 		struct binder_proc **target_procs = NULL, *target_proc;
 		int target_procs_count = 0, i = 0;
+		int init_ns_pid = 0;
 
 		ret = 0;
 
@@ -5875,9 +5915,15 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 			goto err;
 		}
 
+		init_ns_pid = binder_convert_to_init_ns_tgid(info.pid);
+		if (init_ns_pid < 0) {
+			ret = init_ns_pid;
+			goto err;
+		}
+
 		mutex_lock(&binder_procs_lock);
 		hlist_for_each_entry(target_proc, &binder_procs, proc_node) {
-			if (target_proc->pid == info.pid)
+			if (target_proc->pid == init_ns_pid)
 				target_procs_count++;
 		}
 
@@ -5898,7 +5944,7 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 		}
 
 		hlist_for_each_entry(target_proc, &binder_procs, proc_node) {
-			if (target_proc->pid != info.pid)
+			if (target_proc->pid != init_ns_pid)
 				continue;
 
 			binder_inner_proc_lock(target_proc);
-- 
2.25.1

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

[jongan.kim]

From: "JongAn Kim" <jongan.kim@lge.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.

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

This change ensures correct PID handling when binder freeze occurs in
non-init PID namespace.

Signed-off-by: JongAn Kim <jongan.kim@lge.com>
---
 drivers/android/binder.c | 52 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a3a1b5c33ba3..337d1f2c4533 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -5607,6 +5607,40 @@ static bool binder_txns_pending_ilocked(struct binder_proc *proc)
 	return false;
 }
 
+/**
+ * binder_convert_to_init_ns_tgid() - Convert pid to global pid(init namespace)
+ * @pid:    pid from user space
+ *
+ * Converts a process ID (TGID) from the caller's PID namespace to the
+ * corresponding TGID in the init namespace.
+ *
+ * Return: On success, returns TGID in init namespace (positive value).
+ *         On error, returns -EINVAL if pid <= 0, or -ESRCH if process
+ *         not found or not visible in init namespace.
+ */
+static int binder_convert_to_init_ns_tgid(int pid)
+{
+	struct task_struct *task;
+	int init_ns_pid;
+
+	/* already in init namespace */
+	if (task_is_in_init_pid_ns(current))
+		return pid;
+
+	if (pid <= 0)
+		return -EINVAL;
+
+	rcu_read_lock();
+	task = pid_task(find_vpid(pid), PIDTYPE_PID);
+	init_ns_pid = task ? task_tgid_nr_ns(task, &init_pid_ns) : -ESRCH;
+	rcu_read_unlock();
+
+	if (!init_ns_pid)
+		return -ESRCH;
+
+	return init_ns_pid;
+}
+
 static void binder_add_freeze_work(struct binder_proc *proc, bool is_frozen)
 {
 	struct binder_node *prev = NULL;
@@ -5715,13 +5749,18 @@ static int binder_ioctl_get_freezer_info(
 	struct binder_proc *target_proc;
 	bool found = false;
 	__u32 txns_pending;
+	int init_ns_pid = 0;
 
 	info->sync_recv = 0;
 	info->async_recv = 0;
 
+	init_ns_pid = binder_convert_to_init_ns_tgid(info->pid);
+	if (init_ns_pid < 0)
+		return init_ns_pid;
+
 	mutex_lock(&binder_procs_lock);
 	hlist_for_each_entry(target_proc, &binder_procs, proc_node) {
-		if (target_proc->pid == info->pid) {
+		if (target_proc->pid == init_ns_pid) {
 			found = true;
 			binder_inner_proc_lock(target_proc);
 			txns_pending = binder_txns_pending_ilocked(target_proc);
@@ -5867,6 +5906,7 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 		struct binder_freeze_info info;
 		struct binder_proc **target_procs = NULL, *target_proc;
 		int target_procs_count = 0, i = 0;
+		int init_ns_pid = 0;
 
 		ret = 0;
 
@@ -5875,9 +5915,15 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 			goto err;
 		}
 
+		init_ns_pid = binder_convert_to_init_ns_tgid(info.pid);
+		if (init_ns_pid < 0) {
+			ret = init_ns_pid;
+			goto err;
+		}
+
 		mutex_lock(&binder_procs_lock);
 		hlist_for_each_entry(target_proc, &binder_procs, proc_node) {
-			if (target_proc->pid == info.pid)
+			if (target_proc->pid == init_ns_pid)
 				target_procs_count++;
 		}
 
@@ -5898,7 +5944,7 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 		}
 
 		hlist_for_each_entry(target_proc, &binder_procs, proc_node) {
-			if (target_proc->pid != info.pid)
+			if (target_proc->pid != init_ns_pid)
 				continue;
 
 			binder_inner_proc_lock(target_proc);
-- 
2.25.1

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

[Greg KH]

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

> 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

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

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

[Alice Ryhl]

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

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

[jongan.kim]

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

As Alice mentioned, since only the freeze operation takes a pid as input, it
receives the local pid of the namespace. This patch converts this pid to the
global pid of the init namespace for matching pid of binder_procs properly.
(binder_procs has `task->group_leader->pid`). Are there any concerns or 
problems for this logic?

Thanks. // JongAn, Kim

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

[Alice Ryhl]

On Thu, Jan 15, 2026 at 05:06:19PM +0900, jongan.kim@lge.com wrote:
> As Alice mentioned, since only the freeze operation takes a pid as input, it
> receives the local pid of the namespace. This patch converts this pid to the
> global pid of the init namespace for matching pid of binder_procs properly.
> (binder_procs has `task->group_leader->pid`). Are there any concerns or 
> problems for this logic?

This isn't new with your changes ... but it does have a race where the
target process dies and gets replaced by a new process with the same pid
just before you invoke the freeze ioctl.

Alice

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

[jongan.kim]

Alice Ryhl @ 2026-01-15  8:41 UTC wrote:
> On Thu, Jan 15, 2026 at 05:06:19PM +0900, jongan.kim@lge.com wrote:
> > As Alice mentioned, since only the freeze operation takes a pid as input, it
> > receives the local pid of the namespace. This patch converts this pid to the
> > global pid of the init namespace for matching pid of binder_procs properly.
> > (binder_procs has `task->group_leader->pid`). Are there any concerns or 
> > problems for this logic?
>
> This isn't new with your changes ... but it does have a race where the
> target process dies and gets replaced by a new process with the same pid
> just before you invoke the freeze ioctl.

Thanks for sharing! Has this issue been encountered before? I think there may
be a potential problem, although it is very unlikely to occur. (It is also very
hard to fix and verify the problem I guess...)
For now I want to focus on the patch submitted regarding the PID namespace on
this thread. Please check if there are any issues with merging this patch into
the binder driver.

Thanks. // JongAn, Kim

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

[Alice Ryhl]

On Fri, Jan 16, 2026 at 02:52:22PM +0900, jongan.kim@lge.com wrote:
> Alice Ryhl @ 2026-01-15  8:41 UTC wrote:
> > On Thu, Jan 15, 2026 at 05:06:19PM +0900, jongan.kim@lge.com wrote:
> > > As Alice mentioned, since only the freeze operation takes a pid as input, it
> > > receives the local pid of the namespace. This patch converts this pid to the
> > > global pid of the init namespace for matching pid of binder_procs properly.
> > > (binder_procs has `task->group_leader->pid`). Are there any concerns or 
> > > problems for this logic?
> >
> > This isn't new with your changes ... but it does have a race where the
> > target process dies and gets replaced by a new process with the same pid
> > just before you invoke the freeze ioctl.
> 
> Thanks for sharing! Has this issue been encountered before? I think there may
> be a potential problem, although it is very unlikely to occur. (It is also very
> hard to fix and verify the problem I guess...)
> For now I want to focus on the patch submitted regarding the PID namespace on
> this thread. Please check if there are any issues with merging this patch into
> the binder driver.

I do think it makes sense for freeze to convert pids like this. The Rust
driver should also be updated with the same change at the same time.

Alice

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

[jongan.kim]

Alice Ryhl @ 2026-01-16 10:52 UTC wrote:
> On Fri, Jan 16, 2026 at 02:52:22PM +0900, jongan.kim@lge.com wrote:
> > Alice Ryhl @ 2026-01-15  8:41 UTC wrote:
> > > On Thu, Jan 15, 2026 at 05:06:19PM +0900, jongan.kim@lge.com wrote:
> > > > As Alice mentioned, since only the freeze operation takes a pid as input, it
> > > > receives the local pid of the namespace. This patch converts this pid to the
> > > > global pid of the init namespace for matching pid of binder_procs properly.
> > > > (binder_procs has `task->group_leader->pid`). Are there any concerns or 
> > > > problems for this logic?
> > >
> > > This isn't new with your changes ... but it does have a race where the
> > > target process dies and gets replaced by a new process with the same pid
> > > just before you invoke the freeze ioctl.
> > 
> > Thanks for sharing! Has this issue been encountered before? I think there may
> > be a potential problem, although it is very unlikely to occur. (It is also very
> > hard to fix and verify the problem I guess...)
> > For now I want to focus on the patch submitted regarding the PID namespace on
> > this thread. Please check if there are any issues with merging this patch into
> > the binder driver.
> 
> I do think it makes sense for freeze to convert pids like this. The Rust
> driver should also be updated with the same change at the same time.

Thanks for confirmation. I will update the patch after changing and verifying
the rust driver.

Thanks. // JongAn, Kim

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

[jongan.kim]

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