From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f73.google.com (mail-ej1-f73.google.com [209.85.218.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 6FB353AE6E9 for ; Wed, 21 Jan 2026 15:24:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769009051; cv=none; b=Kq9pCrNxW5nuTFBvtS/1B+TCz1+TbDHBUXSy4Ozz7l2cSU+aNhHQKfjipf3K1dBfQCLlMABQ5bDbGVvzanbwu7eF7gdV9qYyikO7jxSgpg1xNZ/jgj13kRnGQglTiAbCnf+zZngfQEUqmDU4eYuOrB6J85VRXhi5aUPIUOLs9A0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769009051; c=relaxed/simple; bh=b9+vKk6fpV0/bfqxdUsLvysdweB8xoV3mUdDKnwkal8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=sdD+PTfjI7NrLtlqJuS5bw+jLGenO9cGufJSkcoYRM3RcMYS7sXWNYQYKjR6gutKYV9D4qr54f/XK2C1F+MdMyoJxeyUtq+Ai1FfIcUuutKFJRzu6BteoaCX7c1cmvHsxFsUAYEt1nOZboyW3eNTNrrKEIUCs9e0Y6YHIto8Yx8= 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=knTBMt3o; arc=none smtp.client-ip=209.85.218.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="knTBMt3o" Received: by mail-ej1-f73.google.com with SMTP id a640c23a62f3a-b874c325d10so1054996066b.1 for ; Wed, 21 Jan 2026 07:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769009048; x=1769613848; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=P6ajID+rZne5e9R1dVGqHhj4CO0LeAgc7DZ9dTnxDK0=; b=knTBMt3odII/25kJggLyyj6nIvWblTMsAy2Etcd87xS9NQ3rCAnNFrCWD7tHQsXFiP JZuvynboodQzy7lVd6toCUMqb4JGiVzryYyoBbJOzOhIEqn44NE4nlPq6i7AYdUzRMRk MvYr37Re+1Cu7L7rtyVLLshu6naDreNLRVao12dnRImBeTfbRieQP6FnAsA9hcErZw1i +2xDj42CtDuIC6FqGxulJLKkV6jJESjvgzBN4w2hokPrPqyh7VQ7uSJpb56MKjoFvovg Sy56optuw7dpl8aSCQaFcUdBBNltsHGOfBwM5LPcfHrhidi91Ly0a0lAbITNWzx2svRc 2RXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769009048; x=1769613848; h=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=P6ajID+rZne5e9R1dVGqHhj4CO0LeAgc7DZ9dTnxDK0=; b=pTip6e43jOLBZTvNd5VK1oFtCjudALDwmPAR1bG81d3MuKVe98ayTam9diBSn1DXUU pwhe0wfoLs3hSbIAkMJxdNR9R7MA5F2Qe6mvRMo064ZRZx5USIprPo4BtsbzN8d6Cz0w IqG5S/OaDJC2emx/u0p8hmNwJH9GEk2QNapffb0hPk66eKg+gQn/KzpyXAXPsZrUTY+t 74pEGXMtzcxdwP6bPJC8uavWWaQU1fzGoBGnT1dLr8I3sYzDYm+ZVZ8mlUfhPy0XLGAQ VPLo7UeZI4+k1dEk3c8WymqoWlPINAGoqeGdyGZLj88ETawBo3/3iOJ1ibsx6Ien8GUa JAEA== X-Forwarded-Encrypted: i=1; AJvYcCX1DZK+6z38XRBFsjOtwHRK0YBdIaJ8f/DZOlDo9weVDooiid4nuxiJnkMDBdUDuzLr1pvkadZJ7YQWoiM=@vger.kernel.org X-Gm-Message-State: AOJu0YxuY754Rc5Uno7zue9cxBig8Ir3+dwlu78zin4MlRy6Oz/dWD+3 poXrYLD8I039zooqAj6Bql7yV5P8o21Bap0QGosMaC3HIsV/nmL7J6IVWhv5jpdOkP5cRlFPu4u q8i7HLSxkfCUTQhRSjQ== X-Received: from ejbjy30.prod.google.com ([2002:a17:906:cade:b0:b86:fedc:879f]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:c22:b0:b72:b289:6de3 with SMTP id a640c23a62f3a-b8796bc4f7emr1728663866b.58.1769009047796; Wed, 21 Jan 2026 07:24:07 -0800 (PST) Date: Wed, 21 Jan 2026 15:24:06 +0000 In-Reply-To: <20260121145005.120507-1-cmllamas@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260121145005.120507-1-cmllamas@google.com> Message-ID: Subject: Re: [PATCH] binder: fix UAF in binder_netlink_report() From: Alice Ryhl To: Carlos Llamas Cc: Greg Kroah-Hartman , "Arve =?utf-8?B?SGrDuG5uZXbDpWc=?=" , Todd Kjos , Christian Brauner , Li Li , kernel-team@android.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="utf-8" On Wed, Jan 21, 2026 at 02:50:04PM +0000, Carlos Llamas wrote: > Oneway transactions sent to frozen targets via binder_proc_transaction() > return a BR_TRANSACTION_PENDING_FROZEN error but they are still treated > as successful since the target is expected to thaw at some point. It is > then not safe to access 't' after BR_TRANSACTION_PENDING_FROZEN errors > as the transaction could have been consumed by the now thawed target. > > This is the case for binder_netlink_report() which derreferences 't' > after a pending frozen error, as pointed out by the following KASAN > report: > > ================================================================== > BUG: KASAN: slab-use-after-free in binder_netlink_report.isra.0+0x694/0x6c8 > Read of size 8 at addr ffff00000f98ba38 by task binder-util/522 > > CPU: 4 UID: 0 PID: 522 Comm: binder-util Not tainted 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT > Hardware name: linux,dummy-virt (DT) > Call trace: > binder_netlink_report.isra.0+0x694/0x6c8 > binder_transaction+0x66e4/0x79b8 > binder_thread_write+0xab4/0x4440 > binder_ioctl+0x1fd4/0x2940 > [...] > > Allocated by task 522: > __kmalloc_cache_noprof+0x17c/0x50c > binder_transaction+0x584/0x79b8 > binder_thread_write+0xab4/0x4440 > binder_ioctl+0x1fd4/0x2940 > [...] > > Freed by task 488: > kfree+0x1d0/0x420 > binder_free_transaction+0x150/0x234 > binder_thread_read+0x2d08/0x3ce4 > binder_ioctl+0x488/0x2940 > [...] > ================================================================== > > Instead, make a transaction copy so the data can be safely accessed by > binder_netlink_report() after a pending frozen error. > > Cc: stable@vger.kernel.org > Fixes: 63740349eba7 ("binder: introduce transaction reports via netlink") > Signed-off-by: Carlos Llamas > --- > drivers/android/binder.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c > index 535fc881c8da..70dc63a6e06a 100644 > --- a/drivers/android/binder.c > +++ b/drivers/android/binder.c > @@ -3780,6 +3780,14 @@ static void binder_transaction(struct binder_proc *proc, > goto err_dead_proc_or_thread; > } > } else { > + /* > + * Make a transaction copy. It is not safe to access 't' after > + * binder_proc_transaction() reported a pending frozen. The > + * target could thaw and consume the transaction at any point. > + * Instead, use a safe 't_copy' for binder_netlink_report(). > + */ > + struct binder_transaction t_copy = *t; > + > BUG_ON(target_node == NULL); > BUG_ON(t->buffer->async_transaction != 1); > return_error = binder_proc_transaction(t, target_proc, NULL); > @@ -3790,7 +3798,7 @@ static void binder_transaction(struct binder_proc *proc, > */ > if (return_error == BR_TRANSACTION_PENDING_FROZEN) { > tcomplete->type = BINDER_WORK_TRANSACTION_PENDING; > - binder_netlink_report(proc, t, tr->data_size, > + binder_netlink_report(proc, &t_copy, tr->data_size, Erm, this solution seems dangerous to me. You access t->to_proc and t->to_thread inside binder_netlink_report(), and if t has been freed, could the same apply to t->to_proc or t->to_thread? After looking a bit more: I can see now that you do call if (target_thread) binder_thread_dec_tmpref(target_thread); binder_proc_dec_tmpref(target_proc); if (target_node) binder_dec_node_tmpref(target_node); after this ... so I guess it can't go wrong in this particular way. But I'm concerned that we will add fields in the future where this is not the case. For example, let's say that tomorrow I want to include t->buffer->clear_on_free in the printed data. If the transaction is freed, then t->buffer might also be freed. Alice