Gentle Ping Alex On 9/18/2026 6:01 PM, Zhu, Lingshan wrote:
> 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 >>>
