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

  - ceph：修复过时mds_wanted挂起的 __ceph_get_caps（） 当客户端不再持有“FILE_RD”，但本地端点状态仍表示已需要此功能时，阅读器可在 __ceph_get_caps（） 中永久挂起（通过“mds_wanted”）。触发此漏洞的一种方法是通过 MDS 端点吊销。如果另一个客户端执行冲突操作，MDS 可从阅读器中撤消“FILE_RD”;然后下一次读取必须重新获取“FILE_RD”。如果应请求“FILE_RD”的端点更新在“cap->mds_wanted”升高后从未到达 MDS，则阅读器仅保留非文件端点，而本地“mds_wanted”仍包含文件读取端点。在该状态下，try_get_cap_refs（） 看到“need <= mds_wanted”并返回 0，因此
    __ceph_get_caps（） 只是在“i_cap_wq”上等待。如果本应请求“FILE_RD的端点更新在”cap->mds_wanted was 提出“后从未到达 MDS，则不会再发送任何请求，且等待程序可无限期休眠，直到不相关的端点流量恰好将其唤醒为止。排序问题在于，在“CEPH_MSG_CLIENT_CAPS message”实际排队等待发送之前，__prep_cap（） 中的“cap->mds_wanted”已更新。这使得一个字段同时提供两种不同的含义：该客户端想要什么，以及客户端认为 MDS 已经知道它想要什么。正确的修复方法是拆分这些状态并跟踪端点更新是否实际在执行中或 MDS 是否已经观察到。但是，稍后仅移动“cap->mds_wanted assignment”是不够的：将 Messenger 中的消息排队并不能保证 MDS 已处理该特定所需集合，重新连接或消息丢失仍可使该假设无效。要正确修复此问题，就需要对端点状态机进行更大规模的返工。
    为了允许更简单的向后移植到稳定内核，此修补程序实现了更简单的变通方案：- 停止在 __ceph_get_caps（） 中永远等待;在有限的等待之后，回退到更新路径 - 每当 inode 仍然未实际持有所需端点时，使 ceph_renew_caps（） 发出同步“OPEN”请求，而非仅调用 ceph_check_caps（） 必须在 ceph_renew_caps（） 中进行额外的 issued-vs-wanted 检查，因为之前的测试仅检查 inode 是否仍有任何实际端点。吊销之后这还不够：客户端仍然可以保留“pLs”之类的内容，但完全缺失“FILE_RD”。在这种情况下，回退到 ceph_check_caps（） 是不够的，因为它仍然信任“cap->mds_wanted”并且可能不发送任何内容。通过在采用异步路径之前要求“（issued & wanted） == wanted”，代码仅在实际已发出“wanted caps”时才使用 ceph_check_caps（）。否则，它发送同步“OPEN”更新。这样可在已发出所需的端点时保留现有的异步快速路径，避免更改端点状态语义，并通过保证等待等待程序最终通过不依赖过时“mds_wanted”状态的路径进行重试来修复挂起。[ idryomov：将CEPH_GET_CAPS_WAIT_TIMEOUT从 libceph.h 移动到 mds_client.h，格式化]（CVE-2026-80527）

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

检测

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

high Nessus 插件 ID 340839

版本 1.9