Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Message-ID: <25f271b5-5cfb-b300-cc1a-764e21e630d5@quicinc.com>
Date:   Mon, 9 Oct 2023 20:21:02 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.0.3
Subject: Re: [PATCH v3] binder: add mutex_lock for mmap and NULL when free
Content-Language: en-US
To:     Carlos Llamas <cmllamas@google.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>
References: <20231007122813.84282-1-quic_yingangl@quicinc.com>
 <ZSHmtLqtNZRAtaZ0@google.com>
From:   Kassey Li <quic_yingangl@quicinc.com>
In-Reply-To: <ZSHmtLqtNZRAtaZ0@google.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2023/10/8 7:16, Carlos Llamas wrote:
> 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...

   lockdep did not warn, but i agree with you, i did not aware the 
mm->mmap_lock. thanks for the remind.
> 
>>   	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.

   looks correct.
> 
>>   	}
>>   	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.

   kasan is trying but not reproduced yet,  we will chasing with this 
test enable kasan.
> 
> --
> Carlos Llamas