Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [Critical] drm_gem_huge_mnt_create() leaves an ERR_PTR or a freed pointer in dev->huge_mnt on failure, leading to cascading failures or Use-After-Free during GEM object creation. -- commit 7e7660e13d434072f394d83fe8c601ac0c32b376 Author: Lu Yao <[email protected]> drm/gem: Fix resource leaks in drm_gem_huge_mnt_create() error paths This commit fixes two resource leaks in the error handling paths of drm_gem_huge_mnt_create() by releasing the filesystem type reference and the fs_context allocated for the mount. > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index e3ed684ddcf29..6f0751d668ad9 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c [ ... ] > @@ -122,19 +122,24 @@ int drm_gem_huge_mnt_create(struct drm_device *dev, > const char *value) [ ... ] > ret = vfs_parse_fs_string(fc, "huge", value); > if (unlikely(ret)) > - return -ENOPARAM; > + goto err; > > dev->huge_mnt = fc_mount_longterm(fc); > put_fs_context(fc); > > return drmm_add_action_or_reset(dev, drm_gem_huge_mnt_free, NULL); [Severity: Critical] This is a pre-existing issue, but does this leave an invalid pointer in dev->huge_mnt on failure? If fc_mount_longterm() fails and returns an ERR_PTR, it gets unconditionally assigned to dev->huge_mnt. If drmm_add_action_or_reset() then succeeds, drm_gem_get_huge_mnt() will later return this ERR_PTR. This bypasses the NULL check in drm_gem_object_init() and causes shmem_file_setup_with_mnt() to fail for subsequent allocations. Additionally, if drmm_add_action_or_reset() fails, it triggers its cleanup action drm_gem_huge_mnt_free(), which calls kern_unmount(dev->huge_mnt). However, dev->huge_mnt is not reset to NULL. Later, drm_gem_object_init() could pass this freed pointer to shmem_file_setup_with_mnt(), resulting in a use-after-free. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
