From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 1C0DC336EE0 for ; Wed, 21 Jan 2026 16:56:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769014593; cv=none; b=fNebcp2hrG8/2TEqbHQdz9lRPZNN+MspTgPFX2pWjfRptf6WImCLs2OBj/A2wmartdm8jjSd+6VKEOKZKMhqZfdgwcdQN36eQNzjOk+J/kUOunj92CQKX88gzcwFr+6YGxtxSN1VVCjY1iE+BfOtipt/oAOICPnGtqJa2yJiLs4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769014593; c=relaxed/simple; bh=XnVzcCbVwpPIAXV3Db+FdhqwiVK0gozlpBoxcNHrWFc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=A+0iEtZuYxA+bnHGDv28Typ3Sf4o93PCzUmIq99Mb//VxQsh2Jbo4/xUPHLWc61YZ8SknoS+8mhp6mrSTdZ0NKYCH8x9/YTHlPyTH0Bp2ahLr3LqZ6hKRVTzQ4nkHMeDJhY3hJ956Ig2HjbvMp/MMgdXbamYdOMfaOfGHKs0M+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=fPXCABDa; arc=none smtp.client-ip=209.85.214.176 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=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fPXCABDa" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2a0d06cfa93so93625ad.1 for ; Wed, 21 Jan 2026 08:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769014591; x=1769619391; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=qiol+dqLjaDH26Yz1t3oEyuKo1Y9NL/hf5slckp3aSc=; b=fPXCABDaVusuyRZNpS0HM1eliDXcBCYEmlXWIGF+Xj06fFOCcKYnjuQO0+BJCF1pGU uLScFc/SgJfALWOp5kKZHo/DkEHpsLxcHOypk8gJw2h8rJccAP6JthFd5Z0Y6y3DIpVD W2n4ho+xHupTajg/7H+8iMOcbHclpUQYkUl9SqRRrvcIzIvjn7QwDB3WT5SHwMb06EBw kZzOk7wFB9igWpMhoPrDVSMSPwS91Xcz0S43t5uzJlU4mGQZniF22bexy4WzLuhV3P9K cG/DEZ5Cpd8vE1nJlPRb8kvQaioo/B5gzZjutVDbcHvRAWXFNJuujfRlvm6z+jiVsbnf GHAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769014591; x=1769619391; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qiol+dqLjaDH26Yz1t3oEyuKo1Y9NL/hf5slckp3aSc=; b=XBaAhes49hNP7dFHLfv0cUaYZde/T6WWboESLMLLYJk08FHw9VsNVdy6c4OFxMuY46 /hQViw/iu2F1Pr0hDUreSJooibtDDxjEqkhNaM9ZvUGPvcaVTygymeB9VtAjvdVa8yFB ZqOwYIZnRZL7j5zQ+ZH/Kh2ftv0d9l78xALHhkf7q/iOtsIGVHsy49H027tFweq8Cdx3 uTKpvvtR1y7cQrVE5UR+7YwYVIKM7eIBIpP9wJB2Zl2KCffc02h8j7phPIcU8eHBtlpE bnHaVLhLGucQ7aMxQugq13b0j1ZsU9qvib7CpPebvgfsH4wbjoyXYr1E0OauPra/fG7G Q5aQ== X-Forwarded-Encrypted: i=1; AJvYcCV9biWTT1PniakAzJNLB7Wz/FUwTIMmcwsYtzHp67l4gna9dVCwVdwVQg0bqK6UGqd7TKyfnvWh2is4HnM=@vger.kernel.org X-Gm-Message-State: AOJu0YxV3nj+0wFGcjuHVi+knROtGWb2PKTdCrps/8jtSfjk7an3inrk pry2XvfjS0DNx3TNa+/qXPTiKzfeS9GdhkKq2VtBqZ9J2kvDka0agh8jpshkB3WMmA== X-Gm-Gg: AZuq6aITdlnwCBiJAuP5HXuu3oA5zw16H72nG1rwqko0d00ckd1Xv8xlB/orJct4Ai5 rZx9DmcWD7ARg8NoaT0HtE1m/9px+EEWkvglY154JodbYLCFX6J2UlK7UjZ9vSnarE814hYBKoa 4AgUyUdt2gd4HgLDGvusYE3W3y0w4lXrylJgmjmL2Nk+mU/E2/IgmvrV3/Bdo4zpwFAt26ERcyQ kpzSFXwwaUFoc8P/Iv408xdcx8wthcvNBAN6ipK3FpsgDGj2pjnFf+IO30AM91IlHu89SFgQSJL nF0ZwztyuTkIdHhSerKXA2R0x9gjm9EAA/nVEddT5M85/IfuneXf1TGdWF4GJqqMaiUMW3eAFLs k5gFiemxPL/1MRZu832XlAgkyRW+gvCvOcWaR87m/yzxE429z1CHJlhovDs4wMNhvNr7UzPkvJo oRzHjIdem4CXAMz7Bp+Oxoi7wSZdgZUGOL2GF0ujyuivxHg+nj3rKU1bzfek21 X-Received: by 2002:a17:902:f550:b0:2a3:cd98:f07 with SMTP id d9443c01a7336-2a7a23cd406mr2729355ad.3.1769014591091; Wed, 21 Jan 2026 08:56:31 -0800 (PST) Received: from google.com (210.53.125.34.bc.googleusercontent.com. [34.125.53.210]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a718f79f40sm159182825ad.0.2026.01.21.08.56.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 08:56:30 -0800 (PST) Date: Wed, 21 Jan 2026 16:56:25 +0000 From: Carlos Llamas To: Alice Ryhl Cc: Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Christian Brauner , Li Li , kernel-team@android.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] binder: fix UAF in binder_netlink_report() Message-ID: References: <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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Jan 21, 2026 at 03:24:06PM +0000, Alice Ryhl wrote: > > 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. Right, the access to the target is safe because of the tmprefs just like the rest of the transaction(). > 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. You actually can't access t->buffer already, there are scenarios where the t->buffer is released before calling binder_netlink_report(). ... There is really nothing dangeours added by this solution. The fragile part you mention comes from passing 't' to binder_netlink_report() in the first place. As opposed to some static struct that contains all the necessary info without potential issues. This is already present. The ideal solution would be to refactor binder_transaction() to have a central place where everything gets populated instead of having separate objects for 'binder_transaction', 'binder_transaction_log_entry' and 'binder_extended_error'. All of them keep duplicated info and we don't need more of them. However, this is a larger effort that would require extensive testing as we might introduce new issues, etc. I'm not sure that we even want to go there. This solves the problem at hand so let's just fix it and move on. -- Carlos Llamas