From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 067134204E; Sun, 7 Jun 2026 10:54:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780829685; cv=none; b=j3KV9A9fK4H1qiob4maCeOJhlK+7QxqLZmYr7YHgb6LkzwwCDJMNOP7apP1qqqSIUqRB6vFz5DOhLay/vKhgoGOJFT6RF7VWn6+v+bDppua82pT+ZaWGY0pogTccqA6jqG7CxsDQqI7OUgkgwgVPwmhxLkCNI3ag39uGvUC5kTo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780829685; c=relaxed/simple; bh=1hz7O4KZ2NjrqP2+V+cm/Yx2wNL2DbqaYEIrPdeewcU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XvtOpoLctJaL0FsZAv4Q1OEketmQF+2bkvCfaVt76awOBP1uTvAcQQm9DrIRfpVGDVmA0nvbZ6XdPgxh8bsAbZSXuRkudCC2qOh/5VLF4y+Bqj2vjrJfd5alTRjh41755vD3sVDRjllE3o3jWJ5zwbDzLos1XT8kITDRfbey/dQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=jdlHkP2T; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="jdlHkP2T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B8D21F00893; Sun, 7 Jun 2026 10:54:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1780829683; bh=XwSrvZ40VsfYMA9dxA7dk1yq6b9F/7MuafSXf3+mUJ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=jdlHkP2TsRM+yqzkpshv+hd0sMRDIPQv2N0kMpEe52hioQZxY7jZ/PjREdCscQbZl kn6bFRM7nMWC3fgvJAw2FrFBeWj6E4+45l3uFqNxQVrBQtWR4Qd+Q+pSDpWtUDLLVi R7choKlSakVwbKQRqmpHGBOV5Ownr9yN2W6Z9xKI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Michael Bommarito , Alex Deucher Subject: [PATCH 7.0 305/332] drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO Date: Sun, 7 Jun 2026 12:01:14 +0200 Message-ID: <20260607095739.277946606@linuxfoundation.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260607095728.031258202@linuxfoundation.org> References: <20260607095728.031258202@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael Bommarito commit 2e7f55eb408c3f72ee1957a0d0ad11d8648a6379 upstream. The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to. The kvcalloc() failure path returns -ENOMEM directly, skipping out_exec and leaking all three. The leaked per-process VM root PD dma_resv lock is the load-bearing leak: any subsequent operation on the same VM (further GEM ops, command-submission, eviction, TTM shrinker callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local denial of service against the caller's GPU context, reachable by any process with /dev/dri/renderD* access. Route the failure through out_exec so drm_exec_fini() and drm_gem_object_put() run. Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GET_MAPPING_INFO on the same fd then blocks in drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the caller does not reap the task; the fd-release path during process exit goes through amdgpu_gem_object_close() -> drm_exec_prepare_obj() on the same lock, leaving the task in D state until the box is rebooted. The patched kernel was not rebuilt and re-tested on this hardware; the fix is mechanical. Tested on a single Lucienne / Vega box only. Ziyi Guo posted an independent INT_MAX-bound check for args->num_entries in the same branch [1]; the two patches are complementary and can land in either order. Fixes: 4d82724f7f2b ("drm/amdgpu: Add mapping info option for GEM_OP ioctl") Link: https://lore.kernel.org/all/20260208000255.4073363-1-n7l8m4@u.northwestern.edu/ # [1] Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Alex Deucher (cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -1096,8 +1096,10 @@ int amdgpu_gem_op_ioctl(struct drm_devic * be retried. */ vm_entries = kvcalloc(args->num_entries, sizeof(*vm_entries), GFP_KERNEL); - if (!vm_entries) - return -ENOMEM; + if (!vm_entries) { + r = -ENOMEM; + goto out_exec; + } amdgpu_vm_bo_va_for_each_valid_mapping(bo_va, mapping) { if (num_mappings < args->num_entries) {