On Thu, Nov 17, 2022 at 2:16 AM Christian König <christian.koenig@xxxxxxx> 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&data=05%7C01%7Cchristian.koenig%40amd.com%7C115292dd7a874278b3ed08dac8701320%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638042680960627756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NYNIAJjt%2FSUXoc3wCz2vPvo%2Be%2FIVcABEA2JYZ8%2F2q04%3D&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) 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. > > 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@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 >
