From: Charan Teja Kalla <quic_charante@quicinc.com>
To: "T.J. Mercier" <tjmercier@google.com>
Cc: "Christian König" <christian.koenig@amd.com>,
zhiguojiang <justinjiang@vivo.com>,
"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, 6 May 2024 15:00:34 +0530 [thread overview]
Message-ID: <83605228-92ee-b666-d894-1c145af2e5ab@quicinc.com> (raw)
In-Reply-To: <8ca45837-cbed-28da-4a6f-0dcec8294f51@quicinc.com>
Hi TJ,
Seems I have got answers from [1], where it is agreed upon epoll() is
the source of issue.
Thanks a lot for the discussion.
[1] https://lore.kernel.org/lkml/0000000000002d631f0615918f1e@google.com/
Thanks
Charan
On 5/5/2024 9:50 PM, Charan Teja Kalla wrote:
> Thanks T.J for the reply!!
>
> On 5/4/2024 4:43 AM, T.J. Mercier wrote:
>> It looks like a similar conclusion about epoll was reached at:
>> https://lore.kernel.org/all/a87d7ef8-2c59-4dc5-ba0a-b821d1effc72@amd.com/
>>
> I am unaware of this discussion. Thanks...
>
>> I agree with Christian that it should not be possible for the file to
>> be freed while inside dma_buf_poll. Aside from causing problems in
>> dma_buf_poll, ep_item_poll itself would have issues dereferencing the
>> freed file pointer.
>>
> Not sure about my understanding: ep_item_poll() always call the ->poll()
> interface with a stable 'struct file' because of ep->mtx. This lock
> ensures that:
> a) If eventpoll_release_file() get the ep->mtx first, ->poll()
> corresponds to the epitem(target file) will never be called, because it
> is removed from the rdlist.
>
> b) If ep_send_events() get the ep->mtx() first, ->poll() will get
> called with a stable 'struct file', __but the refcount(->f_count) of a
> file can be zero__. I am saying that this is stable because the 'struct
> file' contents are still valid till we are in ->poll().
>
> Can you/Christian help me with what I am missing here to say that
> ->poll() is receiving stale 'struct file*', please?
>
> And, If you are convinced with above, I think, It should have been the
> responsibility of ->poll() implementation to have taken refcount on a
> file that is going to be still valid even after ->poll() exits. Incase
> of dma_buf_poll() implementation, it took the refcount on a file that is
> not going to be valid once the dma_buf_poll() exits(because of mentioned
> race with the freeing of the 'struct file*').
>
> So, in dma_buf_poll(), Should we be using atomic_long_inc_not_zero()
> based implementation to take the refcount on a file?
>
> Thanks,
> Charan
next prev parent reply other threads:[~2024-05-06 9:30 UTC|newest]
Thread overview: 24+ 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
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 [this message]
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
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=83605228-92ee-b666-d894-1c145af2e5ab@quicinc.com \
--to=quic_charante@quicinc.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=justinjiang@vivo.com \
--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).