On 9/16/2026 6:18 AM, Deucher, Alexander wrote: > AMD General > >> -----Original Message----- >> From: Zhu, Lingshan <[email protected]> >> Sent: Monday, September 14, 2026 9:55 PM >> To: Deucher, Alexander <[email protected]>; Kuehling, Felix >> <[email protected]> >> Cc: Huang, Ray <[email protected]>; [email protected] >> Subject: RE: [PATCH RESEND 00/10] drm/amdgpu: secure userq lifecycle by its >> kref >> >> AMD General >> >> Gentle Ping Alex > It doesn't look like Christian's concerns were addressed.
Hello Alex, I didn't hear back from Christian for almost two weeks, hope I did not miss any emails This series tries to fix a common use-after-free issues for user queue. The user queues are destroyed when its kref get to zero. So any code paths that work on a user queue has to take a kref of the queue to make sure the queue is alive during its operation. However there are several critical functions does not take a kref of a queue when operate on it, for example mes_userq_reset_queue(patch 6) and gfx_v11_0_userq_priv_fault_work(patch 3). There could be use-after-free bugs if the user space invokes AMDGPU_USERQ_OP_FREE, or close the drm file, or the user space program unexpectedly crashes/exits when kernel processing the user queue without holding a kref. This series tries to fix these problems, and this series is a dependency of the PMC work. Please help Review Thanks Lingshan > > Alex > >> -----Original Message----- >> From: Zhu, Lingshan <[email protected]> >> Sent: Monday, September 14, 2026 9:07 PM >> To: Deucher, Alexander <[email protected]>; Kuehling, Felix >> <[email protected]> >> Cc: Huang, Ray <[email protected]>; [email protected]; Zhu, >> Lingshan <[email protected]> >> Subject: [PATCH RESEND 00/10] drm/amdgpu: secure userq lifecycle by its >> kref >> >> A struct kref is embedded in user queue, which manages the lifecycle of a >> user >> queue. However, several code paths access user queues without hoding the >> kref of a user queue, especially from the doorbell XArray. >> >> These accesses can race with the queue destruction process and result in use- >> after-free bugs. >> >> To fix this issue, this commit: >> 1) Introduces a new helper amdgpu_lookup_queue_by_doorbell, which looks >> up a user queue with locking and hold its kref during access. >> >> 2) Implement asynchronous userq destruction routine, because the last put of >> a queue kref may be placed in a code path where can not sleep or conflict >> locking with the destruction process. >> >> 3) Hold kref during access the user queues >> >> 4) Keep the userq manager alive as long as its queues, to avoid UAF issues. >> >> This seires passed amd_basic tests in igt tests >> >> Link to previus discussions: https://lists.freedesktop.org/archives/amd- >> gfx/2026-August/151692.html >> >> Please help review >> >> Thanks >> Lingshan >> >> Zhu Lingshan (10): >> drm/amdgpu: introduce amdgpu_lookup_queue_by_doorbell >> drm/amdgpu: keep the userq manager alive as long as its queues >> drm/amdgpu/gfx11: hold userq refs in private fault worker >> drm/amdgpu/gfx12: hold userq refs in private fault worker >> drm/amdgpu: implement asynchronous userq destruction routine >> drm/amdgpu: hold userq kref in MES reset >> drm/amdgpu: hold userq kref during isolation scheduling >> drm/amdgpu: hold userq kref during suspend and resume >> drm/amdgpu: free userq by kref_put when fails to create >> drm/amdgpu: take queue kref in userq_create to avoid UAF >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 214 >> +++++++++++++++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h >> | 18 ++ >> drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 7 +- >> drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c | 7 +- >> drivers/gpu/drm/amd/amdgpu/mes_userqueue.c | 46 ++--- >> 5 files changed, 246 insertions(+), 46 deletions(-) >> >> -- >> 2.53.0 >>
