On Thu, Aug 18, 2016 at 7:30 PM, ZhaoJunmin Zhao(Junmin)
<zhaojunmin@xxxxxxxxxx> wrote:
>
>
> 在 2016/8/18 23:23, Greg Kroah-Hartman 写道:
>>
>> On Tue, Aug 16, 2016 at 07:44:59PM -0700, Arve Hjønnevåg wrote:
>>>
>>> On Mon, Aug 15, 2016 at 7:58 AM, Greg Kroah-Hartman
>>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>
>>>> On Thu, Jun 16, 2016 at 12:45:33AM +0200, Jann Horn wrote:
>>>>>
>>>>> If /dev/binder is opened and the opener process then e.g. calls execve,
>>>>> proc->vma_vm_mm will still point to the location of the now-freed
>>>>> mm_struct. If the process then calls ioctl(binder_fd, ...), the
>>>>> dangling
>>>>> proc->vma_vm_mm pointer will be compared to current->mm.
>>>>>
>>>>> Let the binder take a reference to the mm_struct to avoid this.
>>>>>
>>>>> v2: use the right refcounter
>>>>>
>>>>> Fixes: a906d6931f3ccaf7de805643190765ddd7378e27
>>>>
>>>>
>>>> Nit, the proper way to do this is:
>>>>
>>>> Fixes: a906d6931f3c ("android: binder: Sanity check at binder ioctl")
>>>>
>>>> You can get that by doing:
>>>> git show -s --abbrev-commit --abbrev=12 --pretty=format:"%h
>>>> (\"%s\")%n" a906d6931f3ccaf7de805643190765ddd7378e27
>>>>
>>>> Also, I'm guessing this should go to the stable kernels that include the
>>>> above patch?
>>>>
>>>
>>> Has this patch been tested?
>
>
> Hi:
> The patch have tested in huawei device.
>
>>>
>>> Does it actually fix anything?
>>>
>>> Changes to vma_vm_mm are normally protected by the mmap_sem it
>>> contains, and is set to NULL in the vma->vm_ops->close call on the
>>> binder vma. The vma_vm_mm pointer is only used to check if the mm
>>> struct that the binder driver was mmapped into is the same mm struct
>>> that the driver just locked (in binder_update_page_range). I don't
>>> think change description here is accurate. If a process calls execve,
>>> the old vma should be closed (and vma_vm_mm cleared) before the
>>> mm_struct that it belongs too is freed.
>>
>>
>> Yeah, this whole thing feels wrong...
>
>
> In huawei device,
> For example: system_server process use many libs,libstagefright,
> Libdrmframework etc.
> In these lib, binder global object exist like static sp<DeathNotifier>
> sDeathNotifier, static sp<IDrmManagerService> sDrmManagerService;
> When system_sever process fork failed, the new child process call exit,
> which will call hook destruction function.
> In destruction, the parent process *binder reference count will be wrong*.
> To protect
> these exception, we need to add the code in binder.
I not sure I follow this.
I see now that there is another patch that got merged that reused the
vma_vm_mm in the ioctl itself, without holding the lock that protects
it in the existing code. It would probably be best to revert that
change too.
>>
>>
>> Combined with the original author's email address now bouncing, so I've
>> reverted this patch from the tree.
>>
>> thanks,
>>
>> greg k-h
>>
>> .
>>
>
--
Arve Hjønnevåg
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
