From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA219211A14 for ; Mon, 15 Jun 2026 23:49:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781567396; cv=none; b=ZjjizlurRju6DU9yeGwFE4ERDR5+2V5enMKHMrzZ3y9m04XEJyWb4nzeaPA0OwF3jcUg5ewSTuPOv5UkziSfg7QiROwtB0aScLCPAVaT5Nu3dY7VkDCi13jawYtTvgFlJuQJbmdlNOItzffW69ujQo2Yi6jJV4yzOSHFhA/c2g0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781567396; c=relaxed/simple; bh=jsWmET/AQFFP8i6jsG6hNNGMZeJE6QhWgj/vewdsDmo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=HDkTv/ToRCyPiU7HxbkqnAYun6pJ1T6MSCkct0Y0amZD3gp6leF4sjZp8+eno3dcoLG0cMES81iAnZ1wciKmp37IMuNTe1uZ/zruP2YtHqnzcSLRLfY+yA+k891fXcfrSxmz0vmQmIMJ9ojxkB8Wv6CWfmw9yhJAqcuMLwMz04M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=bGaM44Ga; arc=none smtp.client-ip=209.85.222.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bGaM44Ga" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-91588056619so285229385a.2 for ; Mon, 15 Jun 2026 16:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781567394; x=1782172194; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=gprRcECG7ocsbu5PmU47wu6Nm9wZMyLlyWu40sXkxu0=; b=bGaM44GayCe2dOvUwsiGQWncOLUPqfUtM5a6aCW7oblsJA723W6aJM2dhyT1siMO3y NfyOuUOwn8dVmtmIb0NGmzXqUotqtKiHQoyX8505RW7EDwInbPDvPTbTq5iIxazw8/xC wUCzu74aU+IeVY3jyPKRQLo0AdgFi6wOS+MrmhZOAmw7c45GtrLWKCcBPVbThViTNZbe s4JifHAzH32JCR+75jXBAoKgGRlMFulNiMIgxKmXUC0S4/5xvXBIHD0ROWg1PMVlAEcs Qld9/3f+eaUwpDuP4p9W+JZuLkV+Zy8PBoQgLXDruchtBPw61MbP9t3MsQlai3HesZGR y1Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781567394; x=1782172194; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gprRcECG7ocsbu5PmU47wu6Nm9wZMyLlyWu40sXkxu0=; b=RYk91v6OpbEbzGISWLVnZSiEQdGS44R0R54pHd8VrYlyr+XhnmhEXjalQSYMZ7CdqE AyovfBFcP+tpw8wlTIfOglaLx0JC9mObqYG1CIOGw08C5krqKaVo+nKItJV2GcXTz4PH /UxzoIIaI3QQdWulQ0Nzpfo1wLmIIESJOcC1hYgLKj4esSWDuYDtmMkejo6kNcrT5uxK Cz7PntvPPnF9zO50TwPx7hHiiKCafIIceza/sb3PtwwJYKjFBc2BgSec0p+FKYnbDgWB GMmEKNgNKR3C5Hb9eBLGJG4HrJtopmqTHx/1VcaMUwsOCQZNUlFvneDhvtehJO8Ud4zy xlww== X-Forwarded-Encrypted: i=1; AFNElJ9UjkVAgaCAse8eUuj5i5ya6PW8oi7RSRPDzvarsxgWoVkjJFsA/zTQWyjBrtYnAdCoTcqgoxvgpzT0b3g=@vger.kernel.org X-Gm-Message-State: AOJu0YynXJzm0Jd+tWPz8vPGqYqmk1nMCcCDGvedYFoO8x3Shd3sKpCg fnA3kYrVN5ixc2zuIW1e5NZGu2r4e9UGL4l/OrMEDqChbKhVb0HH5xua X-Gm-Gg: Acq92OG60FA/qXYf9QUSlQFoydGeV1MynaEdpWCBDg8gyz3xQDLcK0q3D3POTB/F4E4 eZqp6ogjf02DIpC0gdqNvS3bIWvaZVt/3i19MS7Mpz2L5X3CqX/leTA1TqBYm8wDn85N69lLaly +TwgeXj0ldR0w7rlKAnKuYcPx2aFmDVGH76RqERANkSOuWlmza7F/WlprqmItQJdifOT8LhaxF5 h/94uliUZN8z7TIpbRdTHrolPO5S9hrV37CQykE7BvKg6a5EuZiz8hWo4dGsMsTkabyZmm+dDbx qOgzvP4vMdcpMZOgXbBEU0qgIv5GoSgdJkdxVPd3y7dzT65l+MG0ols6nKaQpPjee9yq1GmavB2 4AsEqfPeQ56f3AuKIFKftcA93iVKKeM9yodykdpfr98vzw9yK7vB3jl3JF6s2OUOc44YaXQCmTI kTD2hrQmsRd6bIYaAHlTc3GxCCcmErrCQ+aRSQ1cPWRUf9vOmpA1cEYe2qTXEDJ7qQfPf0k8uB6 2676LUWzk1t X-Received: by 2002:a05:620a:4408:b0:915:f664:2568 with SMTP id af79cd13be357-91c487460c6mr218466785a.50.1781567393694; Mon, 15 Jun 2026 16:49:53 -0700 (PDT) Received: from tropical-turnip.tail32462.ts.net ([216.132.43.94]) by smtp.gmail.com with ESMTPSA id af79cd13be357-9161a00af50sm1387942285a.30.2026.06.15.16.49.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2026 16:49:53 -0700 (PDT) From: Samuel Ainsworth To: =?UTF-8?q?Christian=20K=C3=B6nig?= , Huang Rui Cc: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Matthew Auld , Matthew Brost , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Samuel Ainsworth Subject: [PATCH v1 0/2] drm/ttm: fix bulk_move cursor use-after-free for unevictable resources Date: Mon, 15 Jun 2026 19:49:20 -0400 Message-ID: <20260615234922.151263-1-skainsworth@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A resource added to a bo's bulk_move LRU cursor can become unevictable (pinned or swapped) after it has been added. ttm_resource_del_bulk_move() then skips removing it -- both on free and on ttm_bo_set_bulk_move() during bo teardown -- because the resource is unevictable, leaving the cursor's pos->first/pos->last pointing at it. Once freed, the next allocation on that bulk_move dereferences the dangling cursor (use-after-free) and corrupts the LRU list, which CONFIG_DEBUG_LIST turns into a fatal BUG. In the field this is a hibernation-triggered panic on a Framework 13 (AMD Ryzen 7040): a buffer swapped out during hibernate is closed after resume (amdgpu_gem_object_close -> amdgpu_vm_bo_del -> ttm_bo_set_bulk_move()), which leaves its unevictable resource on the VM's bulk_move cursor; a later GEM allocation on that cursor then faults (drm/amd issue #5387). Patch 1 tracks cursor membership explicitly so the del always undoes the add, regardless of any pin/swap transition. Patch 2 adds kunit regression coverage. Validating the bug (no GPU required, patch 2): - ttm_bo_bulk_move_swapped_free_dangles allocates a resource on a bulk_move cursor, swaps out its bo's ttm so the resource becomes unevictable, frees it, and asserts the cursor no longer references the freed resource. Without the fix this fails: pos->first/pos->last still equal the freed pointer. - ttm_bo_bulk_move_dangling_corrupts then allocates on the same bulk_move; without the fix, KASAN reports a slab-use-after-free in ttm_resource_add_bulk_move(). On the affected machine, a throwaway debug kernel that WARN_ONCE()s when ttm_resource_del_bulk_move() skips an unevictable resource still on the cursor was used to test. It fired during a normal hibernate/resume cycle, via amdgpu_gem_object_close() -> amdgpu_vm_bo_del() -> ttm_bo_set_bulk_move(). That confirmed the production trigger and that the planted state matches the field crash (the ttm_resource.c WARN_ON, then list_del corruption). With the patch 1 fix, both kunit tests pass and the full TTM kunit suite is green (no KASAN report, no CONFIG_DEBUG_LIST splat). Furthermore, I set up a kernel with the fix, built with KASAN + CONFIG_DEBUG_LIST + lockdep, and ran 10 hibernate/resume/GEM-close cycles under GPU load with no use-after-free nor LRU list corruption. I am new to this area, so review of the approach is very welcome -- in particular whether tracking membership on the resource is preferrable vs removing it from the cursor at the point it becomes unevictable. Samuel Ainsworth (2): drm/ttm: don't leave bulk_move cursor dangling for unevictable resources drm/ttm/tests: add bulk_move cursor regression tests drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 163 ++++++++++++++++++++++++ drivers/gpu/drm/ttm/ttm_resource.c | 18 ++- include/drm/ttm/ttm_resource.h | 9 ++ 3 files changed, 187 insertions(+), 3 deletions(-) base-commit: 2c7d5b0a5ec0fc713a7f350806553643e87e6f43 -- 2.54.0