From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (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 7CEDA319603 for ; Thu, 22 Jan 2026 17:49:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769104145; cv=none; b=X4NwhRv6WOg2zrRyx/ImRWOmuV6MwIWhqAM5mVKLSkLBbuwZCtgDBTT7rbr7sLIKK9Uj2yJ/t7tX2HH1ZgzErJCRCNOls1r1oS4ftGENKbU+C6fNC1X7W8qY2rdrfIRWHj3/jdLKcvpLtcWU5Soy3w3dMUv+xTxG0fIUi41YUaY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769104145; c=relaxed/simple; bh=wTsjPAguFxK44aeHyC0et/kZNTjTEFQuWhSCYOzsKNg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=c0UzUwfREREsv6wxvPPWyInTUGp29UN+PIhWwUGunXtEr/yRPwK7HXBt7Ug2JQUNLpK3VxyPKXFdvLWDG/RqBYU7ollIQkvivNYi74xJk+HVmQ5lsrUb8DW0rVndV51LC5HzY6Q7zOAQlii2pk1sbVW1ZpxmdPboonDbCG7G8+Y= 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=2ZZgzra2; arc=none smtp.client-ip=209.85.214.170 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="2ZZgzra2" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2a76b39587aso1895ad.0 for ; Thu, 22 Jan 2026 09:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769104139; x=1769708939; 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=G/5lkZw7jlqAQByX7Ibn/d2+GVrr92pIkdaecAXndWg=; b=2ZZgzra2DdXiiVr72UuJBgrdtlFVCAhEOBizFW6oFzs8tqx1g4N0KsrxpksTLsTIAR 5M18yLnu4VW1iQ7DIfdg0nVapbXP3cakiUkozS0r9/heDDaPWjgCk3XbJ6/p6xmkErik F0pcgSFNcI/dJhqZMGeepZ0Uo5+GcGGTALyQ1vtsC/adCPKYpF3Q3H6+AAXBDKtADNMa nAVpBqqyr56sRgnZgawsDfzgaZyF7fW4Uubh+LcY1+2sT5+fBNDVkQxJrCy7jvh/D9Wt igwosxG49bKHcQpQCik+0t+DIu0Z5IboOfIxmAUx+053YiFruymOvJt7DGSe7MMmoUUe ycQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769104139; x=1769708939; 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=G/5lkZw7jlqAQByX7Ibn/d2+GVrr92pIkdaecAXndWg=; b=UxTqlFfv0A6OCz2EkpDH3zDvsLDyYqq//nPSUHvGGkW4lrUELKDRrwXsO5veKb+Fue rM0HmLgUGGuIAcf109eGU9XuELAy1lZAQ6qkE8sTdtH5gfFNutUT9nXGC5SzUf2GQfWp EOaAOY1rXRGRjhBCnWbGJ6wRYwE5nneF3kScXqB/imkO6zw0MZbBQ7bsNM8/ynL9lkL5 HHlnnk4tFvceNvtN8dQXGpqbgubNvNMZFbyjfgnEKjYgnhbJgkbVz70z2JgVw6i52ujC FAPTHnHA0xdeVpQ4F7VRL1BwHcMBa3Zxrm16gbRshQSulSVDmolFnLlCo70UR8ZIKQwL 2pAA== X-Forwarded-Encrypted: i=1; AJvYcCVDhoCMVl0rGv1Fesa4jVhFwnMYF7pZP5+vZbyHkywRidNm8G6wnDSBK5087qfvfFYp6gDnQaToJFwho34=@vger.kernel.org X-Gm-Message-State: AOJu0Yz8uP9d6gpf7SeHMr/sIQ/wjgJbQ3kAbZlSVVNmXujl4DBL9qL7 1loKKxVufGL/NnW/YcIp/i5eIRkcJd1KsssP+vZFOI2pPRvseTM1s0kqUTKi9Xtydg== X-Gm-Gg: AZuq6aIs/OQjokKS7cul7aCNXrFzYMhTWWBZDew11VxjFgzOTV+R4VaEslXtNaf+kG8 o3H4BklEqTI6FQh3EEKOLiyUx/ZIpr8GLWVWxy0xlCPh5uP/NxxSj4eT/bvRkc0K8R71dhfYUxP avKUyWr66iJhvcRewgDjcXvveJXcyZM8UgXzOWhEVZ/Ua0W7dPtKZGZsP29HCFZLFvHiM4Fs5gC 1Jq64BXWRoNT9ol2ZiHaa/XBESZWvmeiVCiBW4LpqBUR0UBkf/yoQfoh2ySTEvPTXcrNFv7RjHi 3PIf3SZ51Z8cERqXBmmYpgpi/m86jHRM5lnXU+TzIZxB8SYYBux0Zh1ibn5rFTOuOifu8TlQZz6 qZFQSQCdns++lrQyXiywovNYBiGCMB7AJ0AlX710ixYeOkkKeEOVvHR8u8P+lgwhjNdsJeej/+m Oqk2z2fmstsEGGiBn9+xzjblppk8sYaG52iivwGiSz7FAsiBXlvQ== X-Received: by 2002:a17:903:32d1:b0:2a7:6c4e:5914 with SMTP id d9443c01a7336-2a7d4178102mr3380815ad.6.1769104139026; Thu, 22 Jan 2026 09:48:59 -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-2a7193dbb7fsm190952515ad.64.2026.01.22.09.48.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 09:48:58 -0800 (PST) Date: Thu, 22 Jan 2026 17:48:53 +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 Thu, Jan 22, 2026 at 08:27:13AM +0000, Alice Ryhl wrote: > On Wed, Jan 21, 2026 at 04:56:25PM +0000, Carlos Llamas wrote: > > 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(). > > Hmm, I suppose you are right. It may be worth mentioning that you can't > access t->buffer in a comment inside netlink_report? ok, that is a good idea. I'll send a v2.