From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/ttm: Fix bo resource use-after-free Date: Thu, 05 Mar 2026 13:16:40 +1000 Message-ID: In-Reply-To: <20260304-ttm_bo_res_uaf-v1-1-43f20125b67f@igalia.com> References: <20260304-ttm_bo_res_uaf-v1-1-43f20125b67f@igalia.com> <20260304-ttm_bo_res_uaf-v1-1-43f20125b67f@igalia.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Bug Analysis:** The bug was introduced by commit `c06da4b3573a` which cac= hed `bo->resource` into a local variable `res` at the top of `ttm_bo_swapou= t_cb()`. The problem is that `ttm_bo_handle_move_mem()` at line 1160 calls = into the driver's `move` callback (line 157 of the same file), which replac= es `bo->resource` with the new `evict_mem` and frees the old resource. Afte= r this call returns, the local `res` variable points to freed memory. The stale `res` pointer was then used: 1. At the `ttm_resource_del_bulk_move(res, bo)` call 2. At the `ttm_resource_add_bulk_move(res, bo)` call =20 3. At the `ttm_resource_move_to_lru_tail(res)` call =E2=80=94 which is wher= e the NULL deref in the stack trace occurs **Fix correctness:** The fix simply removes the local `res` variable and re= places all uses with `bo->resource`, which always points to the current (va= lid) resource. This is correct because: - After `ttm_bo_handle_move_mem()` completes successfully, `bo->resource` p= oints to the newly allocated system memory resource - The bulk_move and lru_tail operations should operate on the current resou= rce, not the old (freed) one **Minor observations:** - The `place` initialization `{ .mem_type =3D bo->resource->mem_type }` at = line 1110 is fine =E2=80=94 `bo->resource` is valid at function entry and `= place` captures the value (not the pointer). - The fix is appropriately tagged with `Fixes:` and Cc's the relevant maint= ainers. - No concerns about the locking =E2=80=94 the `spin_lock(&bdev->lru_lock)` = sections after the move are operating on the correct (new) resource. **No issues found.** Clean, minimal, correct fix for a real UAF. --- Generated by Claude Code Patch Reviewer