Message-ID: <aab5ec51-fcff-44f2-a4f5-2979bd776a03@amd.com>
Date: Mon, 15 Apr 2024 13:57:21 +0200
From: Christian König <christian.koenig@....com>
To: zhiguojiang <justinjiang@...o.com>, "T.J. Mercier" <tjmercier@...gle.com>
Cc: Sumit Semwal <sumit.semwal@...aro.org>, linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
 linux-kernel@...r.kernel.org, opensource.kernel@...o.com
Subject: Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue

Am 15.04.24 um 12:35 schrieb zhiguojiang:
> 在 2024/4/12 14:39, Christian König 写道:
>> [Some people who received this message don't often get email from 
>> christian.koenig@....com. Learn why this is important at 
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Am 12.04.24 um 08:19 schrieb zhiguojiang:
>>> [SNIP]
>>> -> Here task 2220 do epoll again where internally it will get/put then
>>> start to free twice and lead to final crash.
>>>
>>> Here is the basic flow:
>>>
>>> 1. Thread A install the dma_buf_fd via dma_buf_export, the fd refcount
>>> is 1
>>>
>>> 2. Thread A add the fd to epoll list via epoll_ctl(EPOLL_CTL_ADD)
>>>
>>> 3. After use the dma buf, Thread A close the fd, then here fd refcount
>>> is 0,
>>>   and it will run __fput finally to release the file
>>
>> Stop, that isn't correct.
>>
>> The fs layer which calls dma_buf_poll() should make sure that the file
>> can't go away until the function returns.
>>
>> Then inside dma_buf_poll() we add another reference to the file while
>> installing the callback:
>>
>>                         /* Paired with fput in dma_buf_poll_cb */
>>                         get_file(dmabuf->file);
> Hi,
>
> The problem may just occurred here.
>
> Is it possible file reference count already decreased to 0 and fput 
> already being in progressing just before calling 
> get_file(dmabuf->file) in dma_buf_poll()?

No, exactly that isn't possible.

If a function gets a dma_buf pointer or even more general any reference 
counted pointer which has already decreased to 0 then that is a major 
bug in the caller of that function.

BTW: It's completely illegal to work around such issues by using 
file_count() or RCU functions. So when you suggest stuff like that it 
will immediately face rejection.

Regards,
Christian.

>
>>
>> This reference is only dropped after the callback is completed in
>> dma_buf_poll_cb():
>>
>>         /* Paired with get_file in dma_buf_poll */
>>         fput(dmabuf->file);
>>
>> So your explanation for the issue just seems to be incorrect.
>>
>>>
>>> 4. Here Thread A not do epoll_ctl(EPOLL_CTL_DEL) manunally, so it
>>> still resides in one epoll_list.
>>>   Although __fput will call eventpoll_release to remove the file from
>>> binded epoll list,
>>>   but it has small time window where Thread B jumps in.
>>
>> Well if that is really the case then that would then be a bug in
>> epoll_ctl().
>>
>>>
>>> 5. During the small window, Thread B do the poll action for
>>> dma_buf_fd, where it will fget/fput for the file,
>>>   this means the fd refcount will be 0 -> 1 -> 0, and it will call
>>> __fput again.
>>>   This will lead to __fput twice for the same file.
>>>
>>> 6. So the potenial fix is use get_file_rcu which to check if file
>>> refcount already zero which means under free.
>>>   If so, we just return and no need to do the dma_buf_poll.
>>
>> Well to say it bluntly as far as I can see this suggestion is completely
>> nonsense.
>>
>> When the reference to the file goes away while dma_buf_poll() is
>> executed then that's a massive bug in the caller of that function.
>>
>> Regards,
>> Christian.
>>
>>>
>>> Here is the race condition:
>>>
>>> Thread A Thread B
>>> dma_buf_export
>>> fd_refcount is 1
>>> epoll_ctl(EPOLL_ADD)
>>> add dma_buf_fd to epoll list
>>> close(dma_buf_fd)
>>> fd_refcount is 0
>>> __fput
>>> dma_buf_poll
>>> fget
>>> fput
>>> fd_refcount is zero again
>>>
>>> Thanks
>>>
>>
>

Powered by blists - more mailing lists