All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: zhiguojiang <justinjiang@vivo.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: Fri, 12 Apr 2024 08:39:14 +0200	[thread overview]
Message-ID: <40ac02bb-efe2-4f52-a4f2-7b56d9b93d2c@amd.com> (raw)
In-Reply-To: <e55cad9b-a361-4d27-a351-f6a4f5b8b734@vivo.com>

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

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
>


  reply	other threads:[~2024-04-12  6:39 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 [this message]
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
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=40ac02bb-efe2-4f52-a4f2-7b56d9b93d2c@amd.com \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.