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

["Christian König" <christian.koenig@amd.com>]

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@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&amp;data=05%7C01%7Cchristian.koenig%40amd.com%7C7d87a302d300479ecfa608dac90dc9f4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638043358319479671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=erPl1hGdfLbfCxK3J3xiIR9boJbgj6hPUnCBvZFobog%3D&amp;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.

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