Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [High] drm/imagination: memory leak of fw_obj on allocation error path
--

commit f0dd8a6ab034ccbc4cdc49ac4cbb537593b10a6d
Author: Alexandru Dadu <[email protected]>
Subject: drm/imagination: Fix parameter validation in pvr_fw_object_destroy()

This patch attempts to fix a possible NULL pointer dereference in
pvr_fw_object_destroy() when handling allocation failures in
pvr_fw_object_create_and_map_common() by returning early.

Link: 
https://lore.kernel.org/dri-devel/[email protected]/

> diff --git a/drivers/gpu/drm/imagination/pvr_fw.c 
> b/drivers/gpu/drm/imagination/pvr_fw.c
> index 850a3ec8e7750..9977f4da3d8d7 100644
> --- a/drivers/gpu/drm/imagination/pvr_fw.c
> +++ b/drivers/gpu/drm/imagination/pvr_fw.c
> @@ -1429,6 +1429,12 @@ void pvr_fw_object_destroy(struct pvr_fw_object 
> *fw_obj)
>       struct drm_gem_object *gem_obj = gem_from_pvr_gem(pvr_obj);
>       struct pvr_device *pvr_dev = to_pvr_device(gem_obj->dev);
>  
> +     if (!fw_obj)
> +             return;
> +
> +     if (!fw_obj->gem)
> +             return;

[Severity: High]
Does this code leave the original NULL pointer dereference unfixed?

Since the local variables gem_obj and pvr_dev are declared and initialized
before these new early returns, fw_obj and fw_obj->gem are implicitly
dereferenced by accessing gem_obj->dev before the check is ever reached.
If either is NULL, an oops will still occur at the start of the function.

[ ... ]

> @@ -1439,8 +1445,7 @@ void pvr_fw_object_destroy(struct pvr_fw_object *fw_obj)
>                       return;
>       }
>  
> -     if (fw_obj->gem)
> -             pvr_gem_object_put(fw_obj->gem);
> +     pvr_gem_object_put(fw_obj->gem);
>  
>       kfree(fw_obj);

[Severity: High]
Could the early return added above cause a memory leak regression?

In pvr_fw_object_create_and_map_common(), if pvr_gem_object_create() fails,
fw_obj->gem is set to NULL and the error cleanup path calls
pvr_fw_object_destroy().

The new early return for !fw_obj->gem skips this kfree(fw_obj) at the end of
the function, permanently leaking the firmware object structure.

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/20260922-fix-null-pointer-dereference-v3-1-f099763ed...@imgtec.com?part=1

Reply via email to