From nobody Thu Apr 9 12:54:33 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7970222F177; Mon, 9 Mar 2026 02:22:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773022973; cv=none; b=jlqXKAHv0j7QauVYzD9ghhgWTtjXTiSD58Cj7hohJGjG1gGuxpwNk4mjjmmhFQcHP583F0jiea4GEybVhNT/zbmgULcavQKp+NhbrPlbe8kBua4HuEuF5oF+/y10PrC6QRaYNAMM+T6mvL96YDVo1oQsQdGlBK3T8w4xxnxn73U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773022973; c=relaxed/simple; bh=ek6Q3pgrbgv6btK46kxZUTvf7+ZrdMXGyeriLGTUzAE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OmGEERtclkfWq0hHAy9ukhgTnV9KY6XNHBAsOPLL8xvgexrydmrJjiTaVOklAQhUaNpb95S7grkCaTGgZgkBjTu+LvU/tM3VV3cl9B5pehLMziDI1m+V0Yxwlp18VPi4rhdh8SV6CdGmZ0+oPAVU/RXPTjrKJADkymP1JsRcLBE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=WIPK784+; arc=none smtp.client-ip=117.135.210.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="WIPK784+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=5v sqXiU7O2Yi0ZaDaTEqsKFf1lQiln2PtajqeQs2Nyc=; b=WIPK784+ChbfpAdr+A eQqyQsF+qh4fQjU3PzQZcy5YxlLugkrMrmVXiR3i45iDYOGCsqY8Dg94fvilvW0e hGuTNjPB0hHGq9dWcHQs7xeDJEgAo3m2tVkMJkcSi1+GZi8xBymPq0Ltw8sa475q pVR+VvRydzR2W0fHb/58FHGRE= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g1-4 (Coremail) with SMTP id _____wDXV5TmLq5pRMZoPg--.11725S3; Mon, 09 Mar 2026 10:22:33 +0800 (CST) From: Chenyuan Mi To: alexander.deucher@amd.com, christian.koenig@amd.com Cc: Arunpravin.PaneerSelvam@amd.com, airlied@gmail.com, simona@ffwll.ch, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH 1/2] drm/amdgpu: protect waitq access with userq_mutex in wait IOCTL Date: Mon, 9 Mar 2026 10:22:28 +0800 Message-ID: <20260309022229.63071-2-chenyuan_mi@163.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260309022229.63071-1-chenyuan_mi@163.com> References: <20260309022229.63071-1-chenyuan_mi@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wDXV5TmLq5pRMZoPg--.11725S3 X-Coremail-Antispam: 1Uf129KBjvJXoWxWF17Ww13Xw45AF45XF18Krg_yoW5XryDpr WrKr12kr4DXr429w1UJwnFgFWvgw4xWFWfKFn7Cry3uws8Aas09ryYkFWDXr18CrsrAFW2 qrn7A3y8tF1qkw7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jqD73UUUUU= X-CM-SenderInfo: xfkh055xdqszrl6rljoofrz/xtbC1ArL3mmuLuqxEwAA3q Content-Type: text/plain; charset="utf-8" amdgpu_userq_wait_ioctl() accesses the wait queue object obtained from xa_load() without holding userq_mutex or taking a reference on the queue. A concurrent AMDGPU_USERQ_OP_FREE call can destroy and free the queue between the xa_load() and the subsequent xa_alloc(&waitq->fence_drv_xa, ...), resulting in a use-after-free. This is a regression introduced by commit 4b27406380b0 ("drm/amdgpu: Add queue id support to the user queue wait IOCTL"), which removed the indirect fence_drv_xa_ptr model and its NULL check safety net from commit ed5fdc1fc282 ("drm/amdgpu: Fix the use-after-free issue in wait IOCTL") and replaced it with a direct waitq->fence_drv_xa access, but did not add any lifetime protection around the new waitq pointer. Fix this by holding userq_mutex across the xa_load() and the subsequent fence_drv_xa operations, matching the locking used by the destroy path. Fixes: 4b27406380b0 ("drm/amdgpu: Add queue id support to the user queue wa= it IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Chenyuan Mi --- drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c b/drivers/gpu/= drm/amd/amdgpu/amdgpu_userq_fence.c index 8013260e29dc..1785ea7c18fe 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c @@ -912,8 +912,10 @@ int amdgpu_userq_wait_ioctl(struct drm_device *dev, vo= id *data, */ num_fences =3D dma_fence_dedup_array(fences, num_fences); =20 + mutex_lock(&userq_mgr->userq_mutex); waitq =3D xa_load(&userq_mgr->userq_xa, wait_info->waitq_id); if (!waitq) { + mutex_unlock(&userq_mgr->userq_mutex); r =3D -EINVAL; goto free_fences; } @@ -932,6 +934,7 @@ int amdgpu_userq_wait_ioctl(struct drm_device *dev, voi= d *data, r =3D dma_fence_wait(fences[i], true); if (r) { dma_fence_put(fences[i]); + mutex_unlock(&userq_mgr->userq_mutex); goto free_fences; } =20 @@ -948,8 +951,10 @@ int amdgpu_userq_wait_ioctl(struct drm_device *dev, vo= id *data, */ r =3D xa_alloc(&waitq->fence_drv_xa, &index, fence_drv, xa_limit_32b, GFP_KERNEL); - if (r) + if (r) { + mutex_unlock(&userq_mgr->userq_mutex); goto free_fences; + } =20 amdgpu_userq_fence_driver_get(fence_drv); =20 @@ -961,6 +966,7 @@ int amdgpu_userq_wait_ioctl(struct drm_device *dev, voi= d *data, /* Increment the actual userq fence count */ cnt++; } + mutex_unlock(&userq_mgr->userq_mutex); =20 wait_info->num_fences =3D cnt; /* Copy userq fence info to user space */ --=20 2.53.0 From nobody Thu Apr 9 12:54:33 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3CE1E23536B; Mon, 9 Mar 2026 02:22:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.5 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773022974; cv=none; b=Ej2Fo6vQycmGQkAT//De+UHCi7kXj8T2ckueBU+NP2nucx9gn9lzi06lXV5b9kyxHAiv2kfwC/iQY+5d33pRTzISF1ixoT6rghC86+kvmik3DrYby5WUVE248y7+g9bBpjU2EpTsMrnJ5eI7A5ZpMez5LF27JPHFZbmo4Z5T9aY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773022974; c=relaxed/simple; bh=nuVeqd0X4gQSOXqquM0fYnDUudF8p8CeGHmP1TrOe1I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BtO5ByNXB/I9enYcYvRWB82D01lP9cLA8MdfgfVPCmVRSDpTRXvAP7+CdwJbRmLtNatMhQoFwhdJn/q5RqfL9Io06fIdlYpd1A+IoJnkjkC/Au9QG9h6/0xdbqpowpPJLzK8zhVyOM2LAoJlmQn3mGdBkBrVdjKSQcttScH6KII= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=JJEv5nsB; arc=none smtp.client-ip=220.197.31.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="JJEv5nsB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=Ti SMxkVGdwISC2XAVkS89dpe+kuedJ/12+uHTMAKZHI=; b=JJEv5nsBjIeg9aIDXP SqLOeMQoiFVvGsO+2GliiLj8t13zWQdIkaeuagI0zvaE6HfrrRhiy6CYZVeSRcha 6x6VkCxHnNTTsNXPiuXLtqdw5mXSDeNag+lbH2hY+Zx37wzmK+z3DsRPu4nPw5BX ncHK/z1VCBlMPJCi0AQV5zqFQ= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g1-4 (Coremail) with SMTP id _____wDXV5TmLq5pRMZoPg--.11725S4; Mon, 09 Mar 2026 10:22:37 +0800 (CST) From: Chenyuan Mi To: alexander.deucher@amd.com, christian.koenig@amd.com Cc: Arunpravin.PaneerSelvam@amd.com, airlied@gmail.com, simona@ffwll.ch, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH 2/2] drm/amdgpu: protect queue access in signal IOCTL Date: Mon, 9 Mar 2026 10:22:29 +0800 Message-ID: <20260309022229.63071-3-chenyuan_mi@163.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260309022229.63071-1-chenyuan_mi@163.com> References: <20260309022229.63071-1-chenyuan_mi@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wDXV5TmLq5pRMZoPg--.11725S4 X-Coremail-Antispam: 1Uf129KBjvJXoW7AFWrWFW5Jw1UWF1kXr1kZrb_yoW5JFW3pr 4rGry3Kr18ur4I9a47J3W7WFs7Ka1xXFWrKr4xA34aqw45A3s0vry7KrWDXF4xCrsFkFZF qry8ZrWFyFn0qw7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jg-B_UUUUU= X-CM-SenderInfo: xfkh055xdqszrl6rljoofrz/xtbC9Q3M32muLu0hAQAA3P Content-Type: text/plain; charset="utf-8" amdgpu_userq_signal_ioctl() retrieves the user queue via xa_load() and then dereferences it in amdgpu_userq_fence_read_wptr(), amdgpu_userq_fence_create(), and direct queue->last_fence accesses, all before userq_mutex is acquired by amdgpu_userq_ensure_ev_fence(). A concurrent AMDGPU_USERQ_OP_FREE can destroy and free the queue in this window, leading to a use-after-free. This bug predates the queue-id wait ioctl changes and has been present since the original signal/wait ioctl implementation. Fix this by moving amdgpu_userq_ensure_ev_fence() before xa_load() so that the queue lookup and all subsequent accesses are performed under the userq_mutex that ensure_ev_fence acquires. Add the necessary mutex_unlock() calls to the error paths between the moved ensure_ev_fence and the existing unlock. Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Chenyuan Mi --- drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c b/drivers/gpu/= drm/amd/amdgpu/amdgpu_userq_fence.c index 1785ea7c18fe..7866f583eea4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c @@ -545,23 +545,28 @@ int amdgpu_userq_signal_ioctl(struct drm_device *dev,= void *data, } } =20 - /* Retrieve the user queue */ + /* We are here means UQ is active, make sure the eviction fence is valid = */ + amdgpu_userq_ensure_ev_fence(&fpriv->userq_mgr, &fpriv->evf_mgr); + + /* Retrieve the user queue under userq_mutex (held by ensure_ev_fence) */ queue =3D xa_load(&userq_mgr->userq_xa, args->queue_id); if (!queue) { + mutex_unlock(&userq_mgr->userq_mutex); r =3D -ENOENT; goto put_gobj_write; } =20 r =3D amdgpu_userq_fence_read_wptr(adev, queue, &wptr); - if (r) + if (r) { + mutex_unlock(&userq_mgr->userq_mutex); goto put_gobj_write; + } =20 r =3D amdgpu_userq_fence_alloc(&userq_fence); - if (r) + if (r) { + mutex_unlock(&userq_mgr->userq_mutex); goto put_gobj_write; - - /* We are here means UQ is active, make sure the eviction fence is valid = */ - amdgpu_userq_ensure_ev_fence(&fpriv->userq_mgr, &fpriv->evf_mgr); + } =20 /* Create a new fence */ r =3D amdgpu_userq_fence_create(queue, userq_fence, wptr, &fence); --=20 2.53.0