[PATCH] dma-buf: Fix possible UAF in dma_buf_export

[Christian König]

Am 18.11.22 um 18:05 schrieb T.J. Mercier:
>
>
> On Fri, Nov 18, 2022 at 12:27 AM Christian König 
> <christian.koenig at amd.com> wrote:
>
>     Am 18.11.22 um 03:36 schrieb T.J. Mercier:
>     > On Thu, Nov 17, 2022 at 2:16 AM Christian König
>     > <christian.koenig at amd.com> wrote:
>     >> Am 17.11.22 um 08:48 schrieb Charan Teja Kalla:
>     >>> Sometime back Dan also reported the same issue[1] where I do
>     mentioned
>     >>> that fput()-->dma_buf_file_release() will remove it from the list.
>     >>>
>     >>> But it seems that I failed to notice fput() here calls the
>     >>> dma_buf_file_release() asynchronously i.e. dmabuf that is
>     accessed in
>     >>> the close path is already freed. Am I wrong here?
>     >>>
>     >>> Should we have the __fput_sync(file) here instead of just
>     fput(file)
>     >>> which can solve this problem?
>     >>>
>     >>>
>     [1]https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20220516084704.GG29930%40kadam%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C7d87a302d300479ecfa608dac90dc9f4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638043358319479671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=erPl1hGdfLbfCxK3J3xiIR9boJbgj6hPUnCBvZFobog%3D&reserved=0
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20220516084704.GG29930%40kadam%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7Ca7d0f99c9d8440a4c6d208dac98717cd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638043879326367851%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V38k91cCy446dyGpmRQWTNn5U8u2zSfCAgIRmACukq4%3D&reserved=0>
>     >> That doesn't look like the right solution to me either.
>     >>
>     >> Essentially we have two separate tear down methods for the dma_buf
>     >> object here:
>     >>
>     >> 1. It's not completely initialized and we can call
>     kfree()+module_put()
>     >> to clean up.
>     >>       There is actually a dma_resv_fini() here. That should
>     probably be
>     >> fixed.
>     >>
>     >> 2. The dma_buf object is fully initialized, but creating the
>     sysfs stats
>     >> file failed.
>     >>       In this case we should *not* clean it up like we
>     currently do, but
>     >> rather call fput().
>     >>
>     >> So the right thing to do is a) fix the missing dma_resv_fini()
>     call and
>     >> b) drop the setting d_fsdata=NULL hack and properly return
>     after the fput().
>     >>
>     > This looks right to me if by properly return you mean return
>     > ERR_PTR(ret); at the end of err_sysfs after the fput. (letting
>     > dma_buf_file_release and dma_buf_release do the full cleanup)
>
>     Yes, exactly that's the idea.
>
>     The only alternatives I can see would be to either move allocating
>     the
>     file and so completing the dma_buf initialization last again or just
>     ignore errors from sysfs.
>
>     > If we still want to avoid calling dmabuf->ops->release(dmabuf) in
>     > dma_buf_release like the comment says I guess we could use
>     sysfs_entry
>     > and ERR_PTR to flag that, otherwise it looks like we'd need a bit
>     > somewhere.
>
>     No, this should be dropped as far as I can see. The sysfs cleanup
>     code
>     looks like it can handle not initialized kobj pointers.
>
>
> Yeah there is also the null check in dma_buf_stats_teardown() that 
> would prevent it from running, but I understood the comment to be 
> referring to the release() dma_buf_ops call into the exporter which 
> comes right after the teardown call. That looks like it's preventing 
> the fput task work calling back into the exporter after the exporter 
> already got an error from dma_buf_export(). Otherwise the exporter 
> sees a release() for a buffer that it doesn't know about / thinks 
> shouldn't exist. So I could imagine an exporter trying to double free: 
> once for the failed dma_buf_export() call, and again when the 
> release() op is called later.


Oh, very good point as well. Yeah, then creating the file should 
probably come last.

Regards,
Christian.

>
>     Regards,
>     Christian.
>
>     >
>     >   >
>     >> Regards,
>     >> Christian.
>     >>
>     >>> Thanks,
>     >>> Charan
>     >>> On 11/17/2022 11:51 AM, Gaosheng Cui wrote:
>     >>>> Smatch report warning as follows:
>     >>>>
>     >>>> drivers/dma-buf/dma-buf.c:681 dma_buf_export() warn:
>     >>>>     '&dmabuf->list_node' not removed from list
>     >>>>
>     >>>> If dma_buf_stats_setup() fails in dma_buf_export(), goto
>     err_sysfs
>     >>>> and dmabuf will be freed, but dmabuf->list_node will not be
>     removed
>     >>>> from db_list.head, then list traversal may cause UAF.
>     >>>>
>     >>>> Fix by removeing it from db_list.head before free().
>     >>>>
>     >>>> Fixes: ef3a6b70507a ("dma-buf: call dma_buf_stats_setup after
>     dmabuf is in valid list")
>     >>>> Signed-off-by: Gaosheng Cui <cuigaosheng1 at huawei.com>
>     >>>> ---
>     >>>>    drivers/dma-buf/dma-buf.c | 3 +++
>     >>>>    1 file changed, 3 insertions(+)
>     >>>>
>     >>>> diff --git a/drivers/dma-buf/dma-buf.c
>     b/drivers/dma-buf/dma-buf.c
>     >>>> index b809513b03fe..6848f50226d5 100644
>     >>>> --- a/drivers/dma-buf/dma-buf.c
>     >>>> +++ b/drivers/dma-buf/dma-buf.c
>     >>>> @@ -675,6 +675,9 @@ struct dma_buf *dma_buf_export(const
>     struct dma_buf_export_info *exp_info)
>     >>>>       return dmabuf;
>     >>>>
>     >>>>    err_sysfs:
>     >>>> +    mutex_lock(&db_list.lock);
>     >>>> +    list_del(&dmabuf->list_node);
>     >>>> +    mutex_unlock(&db_list.lock);
>     >>>>       /*
>     >>>>        * Set file->f_path.dentry->d_fsdata to NULL so that when
>     >>>>        * dma_buf_release() gets invoked by dentry_ops, it exits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20221119/a3820bdb/attachment-0001.htm>