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

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

[WenTao Liang]

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.

Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Fixes: 75af0a585af9 ("accel/qaic: Grab ch_lock during QAIC_ATTACH_SLICE_BO")
Cc: stable@vger.kernel.org
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
---
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);
-- 
2.39.5 (Apple Git-154)

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@linuxfoundation.org>

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@vger.kernel.org
> Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
> ---
> 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);

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

[Greg KH]

On Wed, Jul 29, 2026 at 03:19:38PM -0600, Jeff Hugo wrote:
> 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@linuxfoundation.org>
> 
> This tag seems wrong, as there was nothing I can find on V1 in Lore which
> indicates this tag is appropriate.

Yes, I did not suggest any of these, and the author should have
withdrawn all submissions as they were obviously not correct.