From: zhiguojiang <justinjiang@vivo.com>
To: "Christian König" <christian.koenig@amd.com>,
"T.J. Mercier" <tjmercier@google.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
opensource.kernel@vivo.com
Subject: Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue
Date: Mon, 15 Apr 2024 18:35:30 +0800 [thread overview]
Message-ID: <4fedd80c-d5b6-4478-bfd3-02d1ee1a26e5@vivo.com> (raw)
In-Reply-To: <40ac02bb-efe2-4f52-a4f2-7b56d9b93d2c@amd.com>
在 2024/4/12 14:39, Christian König 写道:
> [Some people who received this message don't often get email from
> christian.koenig@amd.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
>>
>
next prev parent reply other threads:[~2024-04-15 10:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 2:29 [PATCH] dmabuf: fix dmabuf file poll uaf issue Zhiguo Jiang
2024-03-29 23:36 ` T.J. Mercier
2024-04-01 6:52 ` zhiguojiang
2024-04-01 12:22 ` Christian König
2024-04-02 6:49 ` zhiguojiang
2024-04-02 8:07 ` Christian König
2024-04-02 18:22 ` T.J. Mercier
2024-04-12 6:19 ` zhiguojiang
2024-04-12 6:39 ` Christian König
2024-04-15 10:35 ` zhiguojiang [this message]
2024-04-15 11:57 ` Christian König
2024-04-18 1:33 ` zhiguojiang
2024-04-18 6:46 ` Christian König
2024-05-03 13:40 ` Charan Teja Kalla
2024-05-03 23:13 ` T.J. Mercier
2024-05-05 16:20 ` Charan Teja Kalla
2024-05-06 9:30 ` Charan Teja Kalla
2024-05-06 19:04 ` T.J. Mercier
2024-05-07 10:10 ` Christian König
2024-05-07 13:39 ` Daniel Vetter
2024-05-07 14:04 ` Christian König
2024-05-07 18:00 ` T.J. Mercier
2024-05-07 20:19 ` Rob Clark
2024-05-08 11:51 ` David Laight
2024-05-08 12:21 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4fedd80c-d5b6-4478-bfd3-02d1ee1a26e5@vivo.com \
--to=justinjiang@vivo.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=opensource.kernel@vivo.com \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).