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://lore.kernel.org/all/20220516084704.GG29930@kadam/
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