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.kerne...
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:
- 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.
- 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