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 <[email protected]> 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/[email protected]?part=1
