Re: [PATCH v2] accel/qaic: fix GEM object refcount leak in qaic_attach_slice_bo_ioctl

[Jeff Hugo]

On 6/28/2026 5:51 AM, WenTao Liang wrote:
> drm_gem_object_lookup() acquires a GEM object reference on success. All
> error paths correctly release it via put_bo, but the success path returns
> without calling drm_gem_object_put(obj). Since list_add_tail does not
> transfer ownership, the GEM object reference is permanently leaked on
> each successful call.

NACK.

put() is specifically not called in the success case as data structures 
which depend on the BO are not released until detach_slice_bo(), which 
happens to be where the corresponding put() is.  It is also not possible 
to successfully call attach_slice() more than once without a 
corresponding detach_slice_bo().

The get() and put() operations for the concerned paths are currently 
balanced, but this patch will actually introduce an unbalanced state 
(extra put() operations).

As far as the impact of not having this patch per the commit text 
(memory leak) I'm aware of many memory stress tests, yet I recall no 
reports of memory leaks from attach_slice().  You will need to provide 
proof, from actual testing, that this is an issue.

> Suggested-by: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>

This tag seems wrong, as there was nothing I can find on V1 in Lore 
which indicates this tag is appropriate.

> Fixes: 75af0a585af9 ("accel/qaic: Grab ch_lock during QAIC_ATTACH_SLICE_BO")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: WenTao Liang <vulab@xxxxxxxxxxx>
> ---
> Changes in v2:
> - Fix patch format based on reviewer feedback
> ---
>   drivers/accel/qaic/qaic_data.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/accel/qaic/qaic_data.c b/drivers/accel/qaic/qaic_data.c
> index 1e4c579d2725..b17df7bf565d 100644
> --- a/drivers/accel/qaic/qaic_data.c
> +++ b/drivers/accel/qaic/qaic_data.c
> @@ -1084,6 +1084,7 @@ int qaic_attach_slice_bo_ioctl(struct drm_device *dev, void *data, struct drm_fi
>   
>   	bo->sliced = true;
>   	list_add_tail(&bo->bo_list, &bo->dbc->bo_lists);
> +	drm_gem_object_put(obj);
>   	srcu_read_unlock(&dbc->ch_lock, rcu_id);
>   	mutex_unlock(&bo->lock);
>   	kfree(slice_ent);