From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E42A72EB5CD for ; Fri, 9 Jan 2026 08:39:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767947964; cv=none; b=DhZl1DhjYrUoKkT09mojk/cR+HpDK0v6guGFk81747c574RBZRnNjiKo1dslJpxKPk0hJcJu1p2e2AnqqHJ1zT4ODWY6EJc3wFgiNO5VbwaZTzy7WGt3OMtZngPrYEGfQxat61jxLuJwVpNXXe6w8FhhdmvTelBHeFGgczgJmIQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767947964; c=relaxed/simple; bh=g21R4XcF6A813V5vbyrcs8iiSwz1E5DKMrC9Pb0wtag=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=muiNP3AOie8TZEnBNbH+ShkzBWh2Joaueezt+6JTHV7NFULQZPV3sAUATWfgBTg8Hfafue8xuUo6o4rZjV185xCly1H/BIpsPwRoyiIDF88Zq9FM8gewNSVEHuXkkVdkGGZch4AQibwIexh3tC5tKJD8H+9OWBxtBfTwEAY6k7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=jsq0e6GW; arc=none smtp.client-ip=209.85.128.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jsq0e6GW" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-477771366cbso32467035e9.0 for ; Fri, 09 Jan 2026 00:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1767947959; x=1768552759; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=SPSoGl1BfRefeHXS2IevCqOmyfdtM5V9opqHP0l3GiY=; b=jsq0e6GWhaZTY3mcy16T9aZZ90ObMro3V+l6lz+acdTwhIXYyb4PwW7iWer8DUptbr DEO+nfdxbykTVq7cCO2axVeWgZgBvNChvwOjX/fOK6aeyFmZuokBiDzTa+byXVC2FH8h 47QFDGpmDDVjdwQ5VX3icwasTwCEorC/CawL3Ol3YOxJuIHk1HzNTwu+PGNOLEQKVZcw m/SkUYw3l1ROHtlDV3j3ZE0URNB8eNZ9dJrkAchvgoIOOHVQ0yZagfR/8vLFGJ8KezMI FeHsAnqyqIEqLZ0y6//9phaoPVuReaiQ44iu7Vd7m8Ntl0f/oGj9t1RONvHsUR3BYJZb 7tog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767947959; x=1768552759; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=SPSoGl1BfRefeHXS2IevCqOmyfdtM5V9opqHP0l3GiY=; b=WkGnBExBx8TGBmFcDY4JqYiyHH+Be9pQDiWiWOzg7dsl8v0i51jsazN+fzJeqwpQ2s IYsdgqDYFjmUhBDqyUC3OpPeHTBGBN7S7QhS0VVevgAu1prHw6Y7VDl42HDZGk7fmSud AGrPUswzBooW1IV40NSNzb1GPRiETEuZbwuctRk+l0Cz2/xSK3aAdbOlOnCaOM7hvtVv eME8bzvFPXZTATDIjkZcRT7aPVSkVATOMLzX2MMGNgVFxQe8rxW7SNkvTq8pQh6q1CAR SZrBrO1H3U6DayJA0Ou9MGyRgq6arD54Eq5WG4c3EE91s7r5ico/1GqNXXGNSFelXQ6P 3UHA== X-Forwarded-Encrypted: i=1; AJvYcCWkA4VkiCy+isIeb5aSvhImot1MbyT5o6LrS/qLDYTWeOViVrAdyez1b22HlQ+1oJBjAGNanoI6zS+cOe4=@vger.kernel.org X-Gm-Message-State: AOJu0YzsYmuOD3QT+NpDOq+l3d4od/D0Mk8OWXqnAeEccxC4qv9Ap0rx vd6l7nWpWrIGkPk+vYAWuoDpmipvplJO5RFnUIZL/yFKBPNqeU3hax7/Xzir45C7ZdPyi3DM3yq TfwjxeW+LXWjKMfX/Bg== X-Google-Smtp-Source: AGHT+IHv9EWv/l2GT+/zDnK6ODtQgTEfAuJMCv0bXAHREOmW4bMdPrztRKY+8R6kVCgxxlO1hHHfmBGrDPSLDWk= X-Received: from wmjy11.prod.google.com ([2002:a7b:cd8b:0:b0:475:d8de:fe5b]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:46ca:b0:477:75eb:a643 with SMTP id 5b1f17b1804b1-47d84b0a8f7mr95403445e9.4.1767947959407; Fri, 09 Jan 2026 00:39:19 -0800 (PST) Date: Fri, 9 Jan 2026 08:39:18 +0000 In-Reply-To: <2026010941-carwash-disabled-c713@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <2026010828-squash-tranquil-7544@gregkh> <696087cf.050a0220.9a5fe.0a86SMTPIN_ADDED_BROKEN@mx.google.com> <2026010941-carwash-disabled-c713@gregkh> Message-ID: Subject: Re: [PATCH RESEND] binder: handle PID namespace conversion for freeze operation From: Alice Ryhl To: Greg KH Cc: jongan.kim@lge.com, arve@android.com, brauner@kernel.org, cmllamas@google.com, ht.hong@lge.com, jungsu.hwang@lge.com, kernel-team@android.com, linux-kernel@vger.kernel.org, sanghun.lee@lge.com, seulgi.lee@lge.com, sunghoon.kim@lge.com, tkjos@android.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 > >=20 > > > On Thu, Jan 08, 2026 at 10:10:11AM +0900, jongan.kim@lge.com wrote: > > > > From: "JongAn Kim" > > > > 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 differe= nt > > > > process with PID 100 in the init namespace. > > > >=20 > > > > This patch fixes the issue by: > > > > 1. Converting the caller's PID from their namespace to init namespa= ce > > > > 2. Matching against binder_proc->pid (which stores init namespace T= GID) > > > > 3. Returning -EINVAL for invalid PIDs and -ESRCH for not-found proc= esses > > > > > > 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 n= eed > > > to handle namespaces. > > >=20 > > > or am I confused as to what is broken here? > > > > > > thanks, > > > > > > greg k-h > >=20 > > As far as we've confirmed, only the binder=E2=80=99s freeze ioctl opera= tion receives > > and processes a pid from user space. (other binder operation except fre= eze > > handles pid as global pid in kernel space.) >=20 > 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 glob= al pid > > of the init namespace, the freeze operation does not function correctly= when=20 > > executed within a separate namespace. Moreover, in cases where duplicat= e pid=20 > > exist, there is a potential risk of freezing an unintended process in t= he init > > namespace. >=20 > 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. >=20 > 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