CVE-2026-53145

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gem: Try to fix change_handle ioctl, attempt 4<br /> <br /> [airlied: just added some comments on how to reenable]<br /> On-list because the cat is out of the bag and we&amp;#39;re clearly not good<br /> enough to figure this out in private. The story thus far:<br /> <br /> 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in<br /> change_handle") tried to fix a race condition between the gem_close and<br /> gem_change_handle ioctls, but got a few things wrong:<br /> <br /> - There&amp;#39;s a confusion with the local variable handle, which is actually<br /> the new handle, and so the two-stage trick was actually applied to the<br /> wrong idr slot. 7164d78559b0 ("drm/gem: fix race between<br /> change_handle and handle_delete") tried to fix that by adding yet<br /> another code block, but forgot to add the error handling. Which meant<br /> we now have two paths, both kinda wrong.<br /> <br /> - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply<br /> another fix, but inconsistently, again because of the handle confusion<br /> - this would be the right fix (kinda, somewhat, it&amp;#39;s a mess) if we&amp;#39;d<br /> do the two-stage approach for the new handle. Except that wasn&amp;#39;t the<br /> intent of the original fix.<br /> <br /> We also didn&amp;#39;t have an igt merged for the original ioctl, which is a big<br /> no-go. This was attempted to address off-list in the original bugfix,<br /> and amd QA people claimed the bug was fixed now. Very clearly that&amp;#39;s not<br /> the case. Here&amp;#39;s my attempt to sort this out:<br /> <br /> - Rename the local variable to new_handle, the old aliasing with<br /> args-&gt;handle is just too dangerously confusing.<br /> <br /> - Merge the gem obj lookup with the two-stage idr_replace so that we<br /> avoid getting ourselves confused there.<br /> <br /> - This means we don&amp;#39;t have a surplus temporary reference anymore, only<br /> an inherited from the idr. A concurrent gem_close on the new_handle<br /> could steal that. Fix that with the same two-stage approach<br /> create_tail uses. This is a bit overkill as documented in the comment,<br /> but I also don&amp;#39;t trust my ability to understand this all correctly, so<br /> go with the established pattern we have from other ioctls instead for<br /> maximum paranoia.<br /> <br /> - Adjust error paths. I&amp;#39;ve tried to make the error and success paths<br /> common, because they are identical except for which handle is removed<br /> and on which we call idr_replace to (re)install the object again. But<br /> that made things messier to read, so I&amp;#39;ve left it at the more verbose<br /> version, which unfortunately hides the symmetry in the entire code<br /> flow a bit.<br /> <br /> - While at it, also replace the 7 space indent with 1 tab.<br /> <br /> And finally, because I flat out don&amp;#39;t trust my abilities here at all<br /> anymore:<br /> <br /> - Disable the ioctl until we have the igt situation and everything else<br /> sorted out on-list and with full consensus.<br /> <br /> v2:<br /> <br /> Sashiko noticed that I didn&amp;#39;t handle the error path for idr_replace<br /> correctly, it must be checked with IS_ERR_OR_NULL like in<br /> gem_handle_delete. So yeah, definitely should just the existing paths<br /> 1:1 because this is endless amounts of tricky.<br /> <br /> Also add the Fixes: line for the original ioctl, I forgot that too.