Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Date:   Sat, 7 Oct 2023 23:16:04 +0000
From:   Carlos Llamas <cmllamas@google.com>
To:     Kassey Li <quic_yingangl@quicinc.com>
Cc:     gregkh@google.com, gregkh@linuxfoundation.org, surenb@google.com,
        arve@android.com, joel@joelfernandes.org, brauner@kernel.org,
        tkjos@android.com, maco@android.com, linux-kernel@vger.kernel.org,
        Sherry Yang <sherryy@android.com>
Subject: Re: [PATCH v3] binder: add mutex_lock for mmap and NULL when free
Message-ID: <ZSHmtLqtNZRAtaZ0@google.com>
References: <20231007122813.84282-1-quic_yingangl@quicinc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231007122813.84282-1-quic_yingangl@quicinc.com>
Precedence: bulk

On Sat, Oct 07, 2023 at 08:28:13PM +0800, Kassey Li wrote:
> - Enforce alloc->mutex in binder_alloc_mmap_handler when add the entry to
>   list.
> 
> - Assign the freed pages/page_ptr to NULL to catch possible use after free
>   with NULL pointer access.
> 
> Fixes: 19c987241ca1 ("binder: separate out binder_alloc functions")
> Fixes: f2517eb76f1f ("android: binder: Add global lru shrinker to binder")
> CC: Todd Kjos <tkjos@android.com>
> CC: Sherry Yang <sherryy@android.com>
> Link: https://lore.kernel.org/all/20231007034046.2352124-1-quic_yingangl@quicinc.com/
> Signed-off-by: Kassey Li <quic_yingangl@quicinc.com>
> ---
> V1 -> V2: Add Fixes info.
> V2 -> V3: Add this history.
> ---
>  drivers/android/binder_alloc.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
> index e3db8297095a..c7d126e04343 100644
> --- a/drivers/android/binder_alloc.c
> +++ b/drivers/android/binder_alloc.c
> @@ -775,6 +775,7 @@ int binder_alloc_mmap_handler(struct binder_alloc *alloc,
>  	}
>  
>  	buffer->user_data = alloc->buffer;
> +	mutex_lock(&alloc->mutex);

At this stage we are already holding the mm->mmap_lock. If you take the
alloc->mutex here you will deadlock. You should see this warning with
lockdep enabled. Also, you don't need the lock here...

>  	list_add(&buffer->entry, &alloc->buffers);
>  	buffer->free = 1;
>  	binder_insert_free_buffer(alloc, buffer);
> @@ -782,7 +783,7 @@ int binder_alloc_mmap_handler(struct binder_alloc *alloc,
>  
>  	/* Signal binder_alloc is fully initialized */
>  	binder_alloc_set_vma(alloc, vma);

This barrier will set the alloc->vma pointer. Once set, it signals that
the alloc-> space has been initialized and it is safe to access.

> -
> +	mutex_unlock(&alloc->mutex);
>  	return 0;
>  
>  err_alloc_buf_struct_failed:
> @@ -856,9 +857,11 @@ void binder_alloc_deferred_release(struct binder_alloc *alloc)
>  				     __func__, alloc->pid, i, page_addr,
>  				     on_lru ? "on lru" : "active");
>  			__free_page(alloc->pages[i].page_ptr);
> +			alloc->pages[i].page_ptr = NULL;
>  			page_count++;
>  		}
>  		kfree(alloc->pages);
> +		alloc->pages = NULL;

The process is dying and there aren't any more references to it. It is
pointless to mark the pages NULL. No one is or will use them after.

>  	}
>  	mutex_unlock(&alloc->mutex);
>  	if (alloc->mm)
> -- 
> 2.25.1
> 

I see that you reported a crash on the previous thread here:
https://lore.kernel.org/all/26988068-8c9f-8591-db6e-44c8105af638@quicinc.com/
...unfortunately, it doesn't seem to me like setting alloc->pages = NULL
would help fix your issue.

I do agree this sounds like a use-after-free though. Are you able to
reproduce the issue with KASAN enabled? This should tell us where the
actual problem is.

--
Carlos Llamas