accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release()

PATCH Applied Artem Dinaburg 2 participants 2 messages Sep 21 – Sep 22 Stable branch

lore

Share & tools

lore

Artem Dinaburg

author

2026-09-21 17:26 UTC #0 lore raw

PATCH 1/1 accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release()

From: Tomer Tayar <[email protected]>

[ Upstream commit 2e8e9a895c4589f124a37fc84d123b5114406e94 ]

The memory manager IDR is currently destroyed when user releases the file descriptor.
However, at this point the user context might be still held, and memory buffers might be still in use.
Later on, calls to release those buffers will fail due to not finding their handles in the IDR, leading to a memory leak.
To avoid this leak, split the IDR destruction from the memory manager fini, and postpone it to hpriv_release() when there is no user context and no buffers are used.

Signed-off-by Tomer Tayar <[email protected]>

Reviewed-by Oded Gabbay <[email protected]>

Signed-off-by Oded Gabbay <[email protected]>

[ Backport to 6.1.y: this tree keeps Habanalabs under drivers/misc
rather than drivers/accel; the source change is otherwise unchanged. ]

Assisted-by LLM

Signed-off-by Artem Dinaburg <[email protected]>

---
Hi Greg, Sasha, and Habanalabs maintainers,

I am backporting smaller CVE backports still missing from 6.1.y. This fix is inherited by v6.6 and every later mainline release, but 6.1.y still has the affected code. The target-specific adjustment is described in the bracketed note above.

Could you please queue it for 6.1.y?

Thanks,
Artem Dinaburg

CVE: CVE-2023-53353

Build: This patch was included in an x86_64 allmodconfig and CONFIG_WERROR=y build.
It produced vmlinux and 9,075 modules; the same four baseline objtool notices appeared, with no new warnings or errors.

AI assistance: An LLM helped find, adapt, and validate this backport; I reviewed the patch and test output.

 drivers/misc/habanalabs/common/device.c         |  9 +++++++++
 drivers/misc/habanalabs/common/habanalabs.h     |  1 +
 drivers/misc/habanalabs/common/habanalabs_drv.c |  1 +
 drivers/misc/habanalabs/common/memory_mgr.c     | 13 ++++++++++++-
 4 files changed, 23 insertions(+), 1 deletion(-)

drivers/misc/habanalabs/common/device.c +9 -0

index 9ee1b6abd8a051..60a9fc65845bf0 100644
@@ -375,6 +375,9 @@ static void hpriv_release(struct kref *ref)
 	mutex_destroy(&hpriv->ctx_lock);
 	mutex_destroy(&hpriv->restore_phase_mutex);
 
+	/* There should be no memory buffers at this point and handles IDR can be destroyed */
+	hl_mem_mgr_idr_destroy(&hpriv->mem_mgr);
+
 	if ((!hdev->pldm) && (hdev->pdev) &&
 			(!hdev->asic_funcs->is_device_idle(hdev,
 				idle_mask,

@@ -464,6 +467,10 @@ static int hl_device_release(struct inode *inode, struct file *filp)
 	hl_release_pending_user_interrupts(hpriv->hdev);
 
 	hl_ctx_mgr_fini(hdev, &hpriv->ctx_mgr);
+
+	/* Memory buffers might be still in use at this point and thus the handles IDR destruction
+	 * is postponed to hpriv_release().
+	 */
 	hl_mem_mgr_fini(&hpriv->mem_mgr);
 
 	hdev->compute_ctx_in_release = 1;

@@ -808,6 +815,7 @@ static int device_early_init(struct hl_device *hdev)
 
 free_cb_mgr:
 	hl_mem_mgr_fini(&hdev->kernel_mem_mgr);
+	hl_mem_mgr_idr_destroy(&hdev->kernel_mem_mgr);
 free_chip_info:
 	kfree(hdev->hl_chip_info);
 free_pf_wq:

@@ -851,6 +859,7 @@ static void device_early_fini(struct hl_device *hdev)
 	mutex_destroy(&hdev->clk_throttling.lock);
 
 	hl_mem_mgr_fini(&hdev->kernel_mem_mgr);
+	hl_mem_mgr_idr_destroy(&hdev->kernel_mem_mgr);
 
 	kfree(hdev->hl_chip_info);

drivers/misc/habanalabs/common/habanalabs.h +1 -0

index 257b94cec6248b..e6eabcdda1c5c0 100644
@@ -3789,6 +3789,7 @@ const char *hl_sync_engine_to_string(enum hl_sync_engine_type engine_type);
 
 void hl_mem_mgr_init(struct device *dev, struct hl_mem_mgr *mmg);
 void hl_mem_mgr_fini(struct hl_mem_mgr *mmg);
+void hl_mem_mgr_idr_destroy(struct hl_mem_mgr *mmg);
 int hl_mem_mgr_mmap(struct hl_mem_mgr *mmg, struct vm_area_struct *vma,
 		    void *args);
 struct hl_mmap_mem_buf *hl_mmap_mem_buf_get(struct hl_mem_mgr *mmg,

drivers/misc/habanalabs/common/habanalabs_drv.c +1 -0

index ae3cab3f4aa55a..3d4eaa7327e318 100644
@@ -222,6 +222,7 @@ int hl_device_open(struct inode *inode, struct file *filp)
 out_err:
 	mutex_unlock(&hdev->fpriv_list_lock);
 	hl_mem_mgr_fini(&hpriv->mem_mgr);
+	hl_mem_mgr_idr_destroy(&hpriv->mem_mgr);
 	hl_ctx_mgr_fini(hpriv->hdev, &hpriv->ctx_mgr);
 	filp->private_data = NULL;
 	mutex_destroy(&hpriv->ctx_lock);

drivers/misc/habanalabs/common/memory_mgr.c +12 -1

index 1936d653699ed0..93a2b9faf419fd 100644
@@ -342,8 +342,19 @@ void hl_mem_mgr_fini(struct hl_mem_mgr *mmg)
 				"%s: Buff handle %u for CTX is still alive\n",
 				topic, id);
 	}
+}
 
-	/* TODO: can it happen that some buffer is still in use at this point? */
+/**
+ * hl_mem_mgr_idr_destroy() - destroy memory manager IDR.
+ * @mmg: parent unified memory manager
+ *
+ * Destroy the memory manager IDR.
+ * Shall be called when IDR is empty and no memory buffers are in use.
+ */
+void hl_mem_mgr_idr_destroy(struct hl_mem_mgr *mmg)
+{
+	if (!idr_is_empty(&mmg->handles))
+		dev_crit(mmg->dev, "memory manager IDR is destroyed while it is not empty!\n");
 
 	idr_destroy(&mmg->handles);
 }

Signature · 1 line

2.39.5

Sasha Levin

maintainer Applied

2026-09-22 02:23 UTC #1 lore raw

Quoted 1 line

Could you please queue it for 6.1.y?

Queued for 6.1, thanks.

One note for the rest of your CVE backlog: 5.15 and 5.10 do not carry the unified memory manager at all, so they are not affected by this one despite the published range starting at 5.1.

Signature · 2 lines

Thanks,
Sasha