CVE-2026-80527— Ceph 内核模块 悬停缺陷
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
在 Linux 内核中，以下漏洞已修复： ceph：修复因 状态陈旧导致的 挂起问题 当客户端不再持有 权限，但本地权限状态仍显示该权限已被请求（通过 标记）时，读操作可能在 中无限期挂起。 触发方式： 一种触发方式是 MDS 撤销权限（cap revocation）。如果另一个客户端执行了冲突操作，MDS 可以从读方（reader）那里撤销 权限；随后的读操作必须重新获取 。如果在设置 后，本应请求 的权限更新消息未能到达 MDS，则读方可能只保留非文件类权限，而本地的 中仍包含文件读权限。 挂起机制： 在此状态
可能的 ATT&CK 技术 3 AI
T1101 T1190 · Exploit Public-Facing Application T1046 · Network Service Discovery影响版本矩阵 18
| 厂商 | 产品 | 版本范围 | 状态 |
|---|---|---|---|
| Linux | Linux | 0a454bdd501ad1aa30bb72e9581efa338ad6ce5c< b5661524c5a45085a866864ca9b8ae2513dfd67a |
affected |
0a454bdd501ad1aa30bb72e9581efa338ad6ce5c< 5e84bc6f67e19fdd192d8b215de728acbfc12572 |
affected | ||
0a454bdd501ad1aa30bb72e9581efa338ad6ce5c< 5fedf279a1ea369d39c8b06dd4547cdc576065d0 |
affected | ||
0a454bdd501ad1aa30bb72e9581efa338ad6ce5c< e05c315b4da0c16ea800ee4b2cb6c617f586d1b5 |
affected | ||
0a454bdd501ad1aa30bb72e9581efa338ad6ce5c< fcce1b3be6d286aa80831e730289f4c062053ae6 |
affected | ||
0a454bdd501ad1aa30bb72e9581efa338ad6ce5c< a3bc6b3e9ef3f5f5cb85a902a30a090c7931127c |
affected | ||
0a454bdd501ad1aa30bb72e9581efa338ad6ce5c< 9e55fe24c548ad3163903eb58bb002d28d32a630 |
affected | ||
0a454bdd501ad1aa30bb72e9581efa338ad6ce5c< 50958bb928bad3bdba9e5d1b7ff4bbadcf6951e6 |
affected | ||
| … +10 条更多 | |||
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-80527 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
ceph: fix hanging __ceph_get_caps() with stale mds_wanted
来源: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix hanging __ceph_get_caps() with stale mds_wanted
A reader can hang forever in __ceph_get_caps() when the client no
longer holds `FILE_RD`, but local cap state still says that the
capability is already wanted (via `mds_wanted`).
One way to trigger this is through MDS cap revocation. If another
client performs a conflicting operation, the MDS can revoke `FILE_RD`
from the reader; the next read then has to reacquire `FILE_RD`. If
the cap update that should request `FILE_RD` never reaches the MDS
after `cap->mds_wanted` was raised, the reader is left holding only
non-file caps while local `mds_wanted` still includes the file read
caps.
In that state, try_get_cap_refs() sees `need <= mds_wanted` and
returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap
update that was supposed to request `FILE_RD never reaches the MDS
after `cap->mds_wanted was` raised, no further request is sent and the
waiter can sleep indefinitely until unrelated cap traffic happens to
wake it up.
The ordering issue is that `cap->mds_wanted` is updated in
__prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually
queued for send. That makes one field serve two different meanings at
once: what this client wants, and what the client believes the MDS
already knows it wants.
A proper fix would be to split those states and track whether a cap
update is actually in flight or has been observed by the MDS.
However, simply moving the `cap->mds_wanted assignment` later would
not be sufficient: queueing the message in the messenger does not
guarantee that the MDS processed that specific wanted set, and
reconnect or message loss can still invalidate that assumption.
Fixing that properly would require a larger rework of the cap state
machine.
To allow simpler backports to stable kernels, this patch implements a
simpler workaround:
- stop waiting forever in __ceph_get_caps(); after a bounded wait,
fall back to the renew path
- make ceph_renew_caps() issue a synchronous `OPEN` request whenever
the inode still does not actually hold the wanted caps, instead of
only calling ceph_check_caps()
The extra issued-vs-wanted check in ceph_renew_caps() is necessary
because the previous test only checked whether the inode still had any
real caps at all. That is not enough after revocation: the client can
still hold something like `pLs` and yet be missing `FILE_RD`
completely. In that case, falling back to ceph_check_caps() is not
sufficient, because it still trusts `cap->mds_wanted` and may resend
nothing. By requiring `(issued & wanted) == wanted` before taking the
asynchronous path, the code only uses ceph_check_caps() when the
`wanted caps` are already actually issued. Otherwise, it sends the
synchronous `OPEN` renew.
This preserves the existing asynchronous fast path when the wanted
caps are already issued, avoids changing cap-state semantics, and
fixes the hang by guaranteeing that a stalled waiter eventually
retries through a path that does not rely on the stale `mds_wanted`
state.
[ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to
mds_client.h, formatting ]
来源: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
来源: CVE Program / CVE List V5
Vulnerability Type
N/A
来源: CVE Program / CVE List V5
受影响产品
二、漏洞 CVE-2026-80527 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-80527 的情报信息
请登录查看更多情报信息。
CVE-2026-80527 补丁与修复 (8)
同批安全公告 · Linux · 2026-08-26 · 共 92 条
| CVE-2026-80561 | 9.8 CRITICAL | libceph 多个不安全解码远程代码执行漏洞 |
| CVE-2026-80587 | 9.8 CRITICAL | Linux内核 MPTCP 缓冲区溢出漏洞 |
| CVE-2026-74737 | 9.8 CRITICAL | TI AM65 CPSW 驱动端口ID提取错误 |
| CVE-2026-80589 | 9.8 CRITICAL | 磁盘块：释放未添加磁盘时停止超时定时器 |
| CVE-2026-80558 | 9.8 CRITICAL | Ceph libceph 模块 OSID 索引缺陷 |
| CVE-2026-74743 | 9.8 CRITICAL | macvlan 继承底层设备头部尾部空间 |
| CVE-2026-74744 | 9.8 CRITICAL | Linux内核ipvlan模块继承headroom/tailroom |
| CVE-2026-80557 | 9.8 CRITICAL | libceph 2.0 越界读取漏洞 |
| CVE-2026-80528 | 9.8 CRITICAL | Ceph 文件回收竞态漏洞 |
| CVE-2026-74752 | 9.8 CRITICAL | SCTP协议Cookie AUTH状态校验前使用漏洞 |
| CVE-2026-80586 | 9.8 CRITICAL | Linux内核 MPTCP 模块异常尺寸处理缺陷 |
| CVE-2026-80519 | 9.8 CRITICAL | OpenVPN 加密回调清理漏洞 |
| CVE-2026-74746 | 9.8 CRITICAL | Netfilter 流表 GC 可见元组发布顺序漏洞 |
| CVE-2026-74751 | 9.4 CRITICAL | RISC-V ZBB strnlen越界读取 |
| CVE-2026-80585 | 9.4 CRITICAL | Linux 内核 MPTCP 快开子流标记错误 |
| CVE-2026-80554 | 9.3 CRITICAL | Linux s390/vfio_ccw 通道程序段数限制 |
| CVE-2026-80551 | 9.3 CRITICAL | s390/vfio_ccw: 确保首个IDAW保持不变 |
| CVE-2026-80553 | 8.8 HIGH | s390/vfio_ccw 队列取消机制 |
| CVE-2026-80552 | 8.8 HIGH | s390/vfio_ccw 缓冲区溢出漏洞 |
| CVE-2026-80576 | 8.8 HIGH | AMD GPU 驱动拒绝超大IB |
显示前 20 条，共 92 条。 查看全部 → →
IV. Related Vulnerabilities
V. Comments for CVE-2026-80527
暂无评论