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