From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: gpu/buddy: Fix use-after-free in split_block() call sites Date: Sat, 16 May 2026 14:58:07 +1000 Message-ID: In-Reply-To: <20260511164217.150237-2-francois.dugast@intel.com> References: <20260511164217.150237-1-francois.dugast@intel.com> <20260511164217.150237-2-francois.dugast@intel.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 **Assessment: Correct and well-explained fix.** The commit message clearly describes the two distinct failure modes: (1) us= e-after-free when the buddy is also free and coalescing frees a block whose= `rb` is still linked, and (2) rbtree corruption when `mark_free()` =E2=86= =92 `rbtree_insert()` is called on a block that's already in the tree. The root cause is that `split_block()` only calls `mark_split()` (which doe= s `rbtree_remove()`) **after** both child allocations succeed (line 514 of = the current tree). On failure, the block remains FREE and linked in the rbt= ree. All four err_undo sites are fixed consistently: ```c + rbtree_remove(mm, block); __gpu_buddy_free(mm, block, false); ``` This matches the existing pattern in `__force_merge()` (current tree line 3= 37): ```c rbtree_remove(mm, block); ... order =3D __gpu_buddy_free(mm, block, true); ``` **Nit:** The `alloc_from_freetree` err_undo path has no buddy guard =E2=80= =94 it unconditionally calls `__gpu_buddy_free` when `tmp !=3D order`. This= is fine because the block IS free (failed split left it free) and `__gpu_b= uddy_free` handles unmerge-able blocks correctly by just calling `mark_free= ()` at the bottom. But a brief comment like the other three sites' "make su= re we merge everything back" would make the asymmetry less surprising. **Tag concern:** `Assisted-by: GitHub Copilot:claude-sonnet-4.6` =E2=80=94 = this is not a recognized kernel tag. The kernel community generally uses `R= eported-by`, `Suggested-by`, `Reviewed-by`, etc. Some maintainers may objec= t to this. Consider whether this needs a different format or should be a `L= ink:` or trailer note instead. **Cc: stable?** This is a real use-after-free bug. If it can be triggered f= rom userspace (large alloc that forces split_block to fail due to memory pr= essure), it likely warrants a `Cc: stable@vger.kernel.org` tag and a `Fixes= :` tag pointing to the commit that introduced the err_undo paths. --- Generated by Claude Code Patch Reviewer