Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - drm/gem：尝试修复 change_handle ioctl，尝试 4 [airlied：刚刚添加了一些关于如何重新启用的评论] 在列表中，因为猫已经出袋子了，我们显然不够好，无法私下解决这个问题。
    到目前为止的故事：5e28b7b94408（drm：在 change_handle 中的 prime 交换前将旧句柄设置为空）尝试修复 gem_close 和 gem_change_handle ioctl 之间的争用条件，但做错了一些事情：- 与本地变量句柄（实际上是新句柄）之间存在混淆，因此两阶段技巧实际上应用于错误的 idr 槽。7164d78559b0 （drm/gem：修复 change_handle 和 handle_delete 之间的争用）尝试通过添加另一个代码块来修复该问题，但忘记添加错误处理。这意味着我们现在有两条路，都有点错误。- dc366607c41c （drm：将旧指针替换为新 idr）尝试应用另一个补丁，但不一致，同样是因为句柄混淆 - 如果我们对新句柄采取两阶段方法，这将是正确的补丁（有点，有点，一团糟）。只不过这不是原始修复的意图。我们也没有为原始 ioctl 合并 igt，这是一个很大的禁忌。此问题曾尝试解决原始缺陷补丁中的不在列表中的问题，而 amd QA 人员声称该缺陷现已修复。很明显，事实并非如此。这是我试图解决这个问题的尝试：- 将本地变量重命名为 new_handle，使用 args->handle 的旧别名太危险了，令人困惑。- 将 gem obj 查找与两阶段idr_replace合并，以避免在那里混淆。- 这意味着我们不再有剩余的临时引用，只有从 idr 继承的引用。new_handle上的并发gem_close可窃取这一点。使用与create_tail使用的相同的两阶段方法修复该问题。正如评论中记录的那样，这有点矫枉过正，但我也不相信我正确理解这一切的能力，所以使用我们从其他 ioctl 中建立的模式来获得最大的偏执狂。- 调整错误路径。我已尝试使错误和成功路径通用，因为它们是相同的，只是删除了哪个句柄以及我们调用 idr_replace 再次（重新）安装对象。但这让事情读起来更混乱，所以我把它保留在更冗长的版本中，不幸的是，这稍微隐藏了整个代码流中的对称性。- 同时，将 7 个空格缩进替换为 1 个制表符。最后，因为我完全不再相信我在这里的能力：- 禁用 ioctl，直到我们得到 igt 情况，并在列表中解决其他所有内容并获得完全共识。v2：Sashiko 注意到我没有正确处理 idr_replace 的错误路径，必须像 gem_handle_delete 中一样用IS_ERR_OR_NULL进行检查。所以，是的，绝对应该只使用 1:1 现有的路径，因为这是无穷无尽的棘手。还为原始 ioctl 添加了 Fixes： 行，我也忘记了。（CVE-2026-53145）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-53145

high Nessus 插件 ID 323438

版本 1.12