linux-kernel - Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 15 Apr 2024 18:35:30 +0800
From: zhiguojiang <justinjiang@...o.com>
To: Christian König <christian.koenig@....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



在 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()?

>
> 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
>>
>