[PATCH] drm/debugfs: fix dentry leak when removing files

[PATCH] drm/debugfs: fix dentry leak when removing files

[raoxu]

From: Xu Rao <raoxu@uniontech.com>

debugfs_lookup() returns a referenced dentry. The caller must drop the
reference after it is done using the dentry.

drm_debugfs_remove_files() removes the looked-up file but never drops
the lookup reference. debugfs_remove() does not consume it.
debugfs_lookup_and_remove() exists for this case and does the dput().

Drop the dentry reference after removing the debugfs file.

Signed-off-by: Xu Rao <raoxu@uniontech.com>
---
 drivers/gpu/drm/drm_debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index ae1c6126c2c5..fbaa53ec2a4c 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -285,6 +285,7 @@ int drm_debugfs_remove_files(const struct drm_info_list *files, int count,

 		drmm_kfree(minor->dev, d_inode(dent)->i_private);
 		debugfs_remove(dent);
+		dput(dent);
 	}
 	return 0;
 }
--
2.50.1

Re: [PATCH] drm/debugfs: fix dentry leak when removing files

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The backing data for the debugfs file (`i_private`) is freed before the file is removed, creating a Use-After-Free vulnerability for concurrent readers.
--

commit 64c6e87c0ad3d93de1579c3c0f9dfebb4d738254
Author: Xu Rao <raoxu@uniontech.com>

drm/debugfs: fix dentry leak when removing files

This commit fixes a dentry leak in drm_debugfs_remove_files by explicitly
calling dput after dropping the looked-up debugfs file, as debugfs_remove
does not consume the lookup reference.

> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index ae1c6126c2c59..fbaa53ec2a4c7 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -285,6 +285,7 @@ int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
>  
>  		drmm_kfree(minor->dev, d_inode(dent)->i_private);
>  		debugfs_remove(dent);

[Severity: High]
This is a pre-existing issue, but does freeing i_private before calling
debugfs_remove() create a use-after-free risk for concurrent readers?

If a concurrent process is actively reading the debugfs file when
drm_debugfs_remove_files() is called, drmm_kfree() will synchronously free
the backing data. While debugfs_remove() does synchronize SRCU to wait
for active readers to finish, that synchronization happens after the
memory has already been freed here. This sequence might allow existing
readers to dereference the freed data while they complete their operations.

> +		dput(dent);
>  	}
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/D43FE6467BFBCD12+20260609053655.2406749-1-raoxu@uniontech.com?part=1