From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758973AbdKPU1L (ORCPT ); Thu, 16 Nov 2017 15:27:11 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:48838 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758174AbdKPU1D (ORCPT ); Thu, 16 Nov 2017 15:27:03 -0500 Date: Thu, 16 Nov 2017 21:27:06 +0100 From: Greg KH To: Todd Kjos Cc: tkjos@google.com, arve@android.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, maco@google.com Subject: Re: [PATCH v2] binder: fix proc->files use-after-free Message-ID: <20171116202706.GA10790@kroah.com> References: <20171116175650.40362-1-tkjos@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171116175650.40362-1-tkjos@google.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 16, 2017 at 09:56:50AM -0800, Todd Kjos wrote: > proc->files cleanup is initiated by binder_vma_close. Therefore > a reference on the binder_proc is not enough to prevent the > files_struct from being released while the binder_proc still has > a reference. This can lead to an attempt to dereference the > stale pointer obtained from proc->files prior to proc->files > cleanup. This has been seen once in task_get_unused_fd_flags() > when __alloc_fd() is called with a stale "files". > > The fix is to always use get_files_struct() to obtain struct_files > so that the refcount on the files_struct is used to prevent > a premature free. proc->files is removed since we get it every > time. > > Signed-off-by: Todd Kjos > --- > drivers/android/binder.c | 63 +++++++++++++++++++++++------------------------- > 1 file changed, 30 insertions(+), 33 deletions(-) For a v2 patch (or v3 or whatever), you need to put below the --- line what changed from the previous version(s). Documentation/SubmittingPatches describes this pretty well :) thanks, greg k-h