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

Charan Teja Kalla quic_charante at quicinc.com
Thu Nov 17 07:48:02 UTC 2022


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


More information about the dri-devel mailing list