检测到新建 CVE Issue，CVE-ID: CVE-2026-80527。

你可以通过以下两种方式使用 CVE 修复服务：

1. 分支影响分析

   • 在本 Issue 下评论：/analysis_branches
   • 系统将自动分析各个分支是否受影响，并在本 Issue 下给出表格形式的分析结果；

2. 在指定分支上创建 PR（修复提交）

   • 在本 Issue 下按如下格式评论（branch、name、email 为必填字段，每个字段单独一行）：

/create_pr

branch: OLK-6.6 OLK-5.10
name: dev
email: dev@devstation.com
backport-engine: opencode

• 说明：
  • branch: 需要创建 PR 的目标分支列表，例如 OLK-6.6 OLK-5.10；
  • name: PR 签名人姓名（如责任人或安全负责人）；
  • email: PR 签名人邮箱；
  • backport-engine（可选）：可选 portgpt、mystique 或 opencode；不填时默认使用 portgpt，建议使用 opencode；

系统会根据上述信息自动在指定分支上创建 PR，并在本 Issue 下反馈结果。

provided by DevStation.

issue处理注意事项:
1. 提交正常修复分支的修复PR时,必须关联当前issue,否则无法关闭当前issue;
2. 模板内容需要填写完整, 无论是受影响或者不受影响都需要填写完整内容;
3. 以下为模板中需要填写完整的内容, 请复制到评论区回复;
注: 内容的关键词(影响性分析说明, openEuler评分, 受影响版本排查(受影响/不受影响), 修复是否涉及abi变化(是/否), 原因说明)不能省略,省略后cve-manager将无法正常解析填写内容.

---

影响性分析说明:

openEuler评分: (评分和向量)

受影响版本排查(受影响/不受影响):
1.master(6.18.40):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP4(5.10.0):
4.openEuler-24.03-LTS-Next(6.6.0):
5.openEuler-24.03-LTS-SP1(6.6.0):
6.openEuler-24.03-LTS-SP3(6.6.0):
7.openEuler-24.03-LTS-SP4(6.6.0):

修复是否涉及abi变化(是/否)：
1.master(6.18.40):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP4(5.10.0):
4.openEuler-24.03-LTS-Next(6.6.0):
5.openEuler-24.03-LTS-SP1(6.6.0):
6.openEuler-24.03-LTS-SP3(6.6.0):
7.openEuler-24.03-LTS-SP4(6.6.0):

原因说明：
1.master(6.18.40):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP4(5.10.0):
4.openEuler-24.03-LTS-Next(6.6.0):
5.openEuler-24.03-LTS-SP1(6.6.0):
6.openEuler-24.03-LTS-SP3(6.6.0):
7.openEuler-24.03-LTS-SP4(6.6.0):

---

原因说明填写请参考下方表格(注意：版本是否受影响和版本的原因说明必须对应，例如master版本分支受影响，那原因说明只能是受影响对应的原因之一!)：

分支状态	原因说明	使用场景
受影响	正常修复	受影响且需要修复（包含升级版本修复）的漏洞； 受影响且已经修复的漏洞（历史修复PR也需要关联issue）； 若因特殊原因无法修复，应修改原因说明为【不修复-特殊原因】，并在安委会备案相关情况。
受影响	漏洞仍在分析中	已关注到相关漏洞，正在处理，未明确漏洞影响和修复方案。
受影响	暂不修复-暂无解决方案或补丁	当前没有可用的修复或补救措施。【影响性分析】中应包含有关为什么没有修复或补救措施的详细说明、上游相关PR等。
受影响	不修复-超出修复范围	没有漏洞的修复计划。当版本停维、软件包宣布生命周期终止或弃用使用。
受影响	不修复-特殊原因导致不再修复	如存在其他特殊情况不修复相关漏洞，或评估后无法升级修复，应在openEuler社区安全委员会例会进行说明备案。 【影响性分析】中应包含不发布修复的详细说明、特殊情况还应有安委会会议纪要。
不受影响	不受影响-组件不存在	软件不受影响，因为易受攻击的组件不在产品中。
不受影响	不受影响-已有内置的内联控制或缓解措施	内置的内联控制或缓解措施可防止攻击者利用漏洞
不受影响	不受影响-漏洞代码不能被攻击者触发	易受攻击的组件存在，并且该组件包含易受攻击的代码。但是，易受攻击的代码的使用方式使得攻击者无法进行任何预期的攻击。
不受影响	不受影响-漏洞代码不在执行路径	易受影响的代码在执行过程中不可访问，包括产品的非预期状态。产品不使用也不执行的组件。
不受影响	不受影响-漏洞代码不存在	产品不受影响，因为漏洞背后的代码在产品中不存在。与component_not_present不同的是，有问题的组件存在，但由于某种原因（例如安全的编译器选项）使漏洞的特定代码不存在于组件中。

issue处理具体操作请参考:
https://atomgit.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
pr关联issue具体操作请参考:
https://docs.atomgit.com/docs/help/home/org_project/pullrequests/pr-related-issue

Welcome To openEuler Community

Hey @openeuler-ci-bot , thanks for your contribution to the community.

Bot Usage Manual

I'm the Bot here serving you. You can find the instructions on how to interact with me at Here . That means you can comment below every pull request or issue to trigger Bot Commands. You can self-configure the PR merge rules for this repository. For more details, please refer to Here.

Contact Guide

If you have any questions, please contact the SIG: Kernel ,
and any of the maintainers: @hanjunguo, @oekernel, @sanglipeng, @wkfxxx, @zeng_zhaorong ,
and any of the committers: @CTC-XiboWang, @Frank_Sae, @GoGo_phytium, @GongLei-, @LiuYongQiang0816, @SuperSix173, @Tankll2021, @TrueAI, @YiweiZ, @allen-shi, @alvin-ling, @baratta, @bibo_mao, @caixu-blue, @chen-jun-hw, @chenjiesong, @chenjunxin1992, @chenke2026, @chiqijun, @chriszjh, @duanqiangwen, @eingesch, @fangfeng123, @fanghaiqinghw, @gang_he, @gaojuxin09, @gouhao2022, @guohaocs2c, @guzitao, @hanjunguo, @hanliyang, @hellotcc, @henryze, @hewanhan, @hjx_gitff, @hongwu-wang, @htforge, @hu-chunzhi, @hunan4222, @jackknight, @jerry_lilijun, @jiayi0118, @junlong-zheng, @juntianlinux, @kailiu42, @kaitiandu, @kazero00, @kevinzhu1, @kile2009, @klmengkd, @koishimind, @kongzizaixian, @kylin-mayukun, @leoliu-oc, @li-huisong, @linan888, @linyunsheng, @liulongfang, @liyihang0226, @lostway1, @lujialin2, @mao-hongbo, @markyuan4ta21, @mawupeng, @mingqian218472, @mingrui-liu, @mufengyan, @pigalsofine, @robinorg, @rock_hw, @sanglipeng, @shu-shengming, @shuaijiakun, @sming56_admin, @stavewu, @stkid, @sun_nanyong, @wangboe2022, @wanghang73, @wenzhiwei11, @whoisxxx, @wkfxxx, @woqidaideshi, @wsoydl, @xingmz1, @xukuohai, @yeweihua999, @ygn-ndwd-official, @yonghu_4dc5, @young-sun, @yubo-liu1, @yuehaibing_planb, @yuzenghui1, @zhang-changzhong, @zhangyi089, @zhujianwei001, @zichengqu, @zouyipeng, @zqiao216 .

参考网址	关联pr	状态	补丁链接
https://www.opencve.io/cve/CVE-2026-80527	None	None	https://git.kernel.org/stable/c/5fedf279a1ea369d39c8b06dd4547cdc576065d0 https://git.kernel.org/stable/c/5e84bc6f67e19fdd192d8b215de728acbfc12572 https://git.kernel.org/stable/c/a3bc6b3e9ef3f5f5cb85a902a30a090c7931127c https://git.kernel.org/stable/c/b5661524c5a45085a866864ca9b8ae2513dfd67a https://git.kernel.org/stable/c/9e55fe24c548ad3163903eb58bb002d28d32a630 https://git.kernel.org/stable/c/50958bb928bad3bdba9e5d1b7ff4bbadcf6951e6 https://git.kernel.org/stable/c/e05c315b4da0c16ea800ee4b2cb6c617f586d1b5 https://git.kernel.org/stable/c/fcce1b3be6d286aa80831e730289f4c062053ae6
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2026-80527
https://security-tracker.debian.org/tracker/CVE-2026-80527
http://www.cnnvd.org.cn/web/vulnerability/queryLds.tag?qcvCnnvdid=CVE-2026-80527
https://nvd.nist.gov/vuln/detail/CVE-2026-80527
https://ubuntu.com/security/CVE-2026-80527	None	None	https://discourse.ubuntu.com/c/project

说明：补丁链接仅供初步排查参考，实际可用性请人工再次确认，补丁下载验证可使用CVE补丁工具。
若补丁不准确，烦请在此issue下评论 '/report-patch 参考网址 补丁链接1,补丁链接2' 反馈正确信息，便于我们不断优化工具，不胜感激。
如 /report-patch https://security-tracker.debian.org/tracker/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1

CVE-2026-80527

影响性分析说明：
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 ]

The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.

openEuler评分:(评分和向量)
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.master:不受影响
2.openEuler-20.03-LTS-SP4:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响
8.openEuler-24.03-LTS-SP2:受影响
9.openEuler-24.03-LTS-SP3:受影响
10.openEuler-24.03-LTS-SP4:受影响

修复是否涉及abi变化(是/否)：
1.master:否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP3:否
4.openEuler-22.03-LTS-SP4:否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否
8.openEuler-24.03-LTS-SP2:否
9.openEuler-24.03-LTS-SP3:否
10.openEuler-24.03-LTS-SP4:否

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:暂不修复-漏洞仍在分析中
3.openEuler-22.03-LTS-SP3:不修复-超出修复范围
4.openEuler-22.03-LTS-SP4:暂不修复-漏洞仍在分析中
5.openEuler-24.03-LTS:不修复-超出修复范围
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:暂不修复-漏洞仍在分析中
8.openEuler-24.03-LTS-SP2:不修复-超出修复范围
9.openEuler-24.03-LTS-SP3:暂不修复-漏洞仍在分析中
10.openEuler-24.03-LTS-SP4:暂不修复-漏洞仍在分析中

@sming56_admin 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	分析项目	内容
已分析	1.影响性分析说明	In the Linux kernel, the following vulnerability has been resolved:ceph: fix hanging __ceph_get_caps() with stale mds_wantedA reader can hang forever in __ceph_get_caps() when the client nolonger holds FILE_RD, but local cap state still says that thecapability is already wanted (via mds_wanted).One way to trigger this is through MDS cap revocation. If anotherclient performs a conflicting operation, the MDS can revoke FILE_RDfrom the reader; the next read then has to reacquire FILE_RD. Ifthe cap update that should request FILE_RD never reaches the MDSafter cap->mds_wanted was raised, the reader is left holding onlynon-file caps while local mds_wanted still includes the file readcaps.In that state, try_get_cap_refs() sees need <= mds_wanted andreturns 0, so __ceph_get_caps() just waits on i_cap_wq. If the capupdate that was supposed to request FILE_RD never reaches the MDSafter cap->mds_wanted wasraised, no further request is sent and thewaiter can sleep indefinitely until unrelated cap traffic happens towake it up.The ordering issue is thatcap->mds_wantedis updated in__prep_cap() before theCEPH_MSG_CLIENT_CAPS messageis actuallyqueued for send. That makes one field serve two different meanings atonce: what this client wants, and what the client believes the MDSalready knows it wants.A proper fix would be to split those states and track whether a capupdate is actually in flight or has been observed by the MDS.However, simply moving thecap->mds_wanted assignmentlater wouldnot be sufficient: queueing the message in the messenger does notguarantee that the MDS processed that specific wanted set, andreconnect or message loss can still invalidate that assumption.Fixing that properly would require a larger rework of the cap statemachine.To allow simpler backports to stable kernels, this patch implements asimpler workaround:- stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path- make ceph_renew_caps() issue a synchronousOPENrequest 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 necessarybecause the previous test only checked whether the inode still had anyreal caps at all. That is not enough after revocation: the client canstill hold something likepLsand yet be missingFILE_RDcompletely. In that case, falling back to ceph_check_caps() is notsufficient, because it still trusts cap->mds_wantedand may resendnothing. By requiring(issued & wanted) == wanted before taking theasynchronous path, the code only uses ceph_check_caps() when thewanted capsare already actually issued. Otherwise, it sends thesynchronousOPENrenew.This preserves the existing asynchronous fast path when the wantedcaps are already issued, avoids changing cap-state semantics, andfixes the hang by guaranteeing that a stalled waiter eventuallyretries through a path that does not rely on the stalemds_wanted`state.[ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.
已分析	2.openEulerScore	7.5
已分析	3.openEulerVector	AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	master:不受影响,openEuler-20.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS-Next:不受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP2:受影响
已分析	5.是否涉及abi变化	master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-SP2:否
已分析	6.原因说明	master:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:漏洞仍在分析中,openEuler-22.03-LTS-SP4:漏洞仍在分析中,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-SP1:漏洞仍在分析中,openEuler-24.03-LTS-SP3:漏洞仍在分析中,openEuler-24.03-LTS-SP4:漏洞仍在分析中,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-SP2:不修复-超出修复范围

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

openEuler评分:(评分和向量)
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

@sming56_admin 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	分析项目	内容
已分析	1.影响性分析说明	In the Linux kernel, the following vulnerability has been resolved:ceph: fix hanging __ceph_get_caps() with stale mds_wantedA reader can hang forever in __ceph_get_caps() when the client nolonger holds FILE_RD, but local cap state still says that thecapability is already wanted (via mds_wanted).One way to trigger this is through MDS cap revocation. If anotherclient performs a conflicting operation, the MDS can revoke FILE_RDfrom the reader; the next read then has to reacquire FILE_RD. Ifthe cap update that should request FILE_RD never reaches the MDSafter cap->mds_wanted was raised, the reader is left holding onlynon-file caps while local mds_wanted still includes the file readcaps.In that state, try_get_cap_refs() sees need <= mds_wanted andreturns 0, so __ceph_get_caps() just waits on i_cap_wq. If the capupdate that was supposed to request FILE_RD never reaches the MDSafter cap->mds_wanted wasraised, no further request is sent and thewaiter can sleep indefinitely until unrelated cap traffic happens towake it up.The ordering issue is thatcap->mds_wantedis updated in__prep_cap() before theCEPH_MSG_CLIENT_CAPS messageis actuallyqueued for send. That makes one field serve two different meanings atonce: what this client wants, and what the client believes the MDSalready knows it wants.A proper fix would be to split those states and track whether a capupdate is actually in flight or has been observed by the MDS.However, simply moving thecap->mds_wanted assignmentlater wouldnot be sufficient: queueing the message in the messenger does notguarantee that the MDS processed that specific wanted set, andreconnect or message loss can still invalidate that assumption.Fixing that properly would require a larger rework of the cap statemachine.To allow simpler backports to stable kernels, this patch implements asimpler workaround:- stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path- make ceph_renew_caps() issue a synchronousOPENrequest 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 necessarybecause the previous test only checked whether the inode still had anyreal caps at all. That is not enough after revocation: the client canstill hold something likepLsand yet be missingFILE_RDcompletely. In that case, falling back to ceph_check_caps() is notsufficient, because it still trusts cap->mds_wantedand may resendnothing. By requiring(issued & wanted) == wanted before taking theasynchronous path, the code only uses ceph_check_caps() when thewanted capsare already actually issued. Otherwise, it sends thesynchronousOPENrenew.This preserves the existing asynchronous fast path when the wantedcaps are already issued, avoids changing cap-state semantics, andfixes the hang by guaranteeing that a stalled waiter eventuallyretries through a path that does not rely on the stalemds_wanted`state.[ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.
已分析	2.openEulerScore	7.5
已分析	3.openEulerVector	AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	master:不受影响,openEuler-20.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS-Next:不受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP2:受影响
已分析	5.是否涉及abi变化	master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-SP2:否
已分析	6.原因说明	master:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:漏洞仍在分析中,openEuler-22.03-LTS-SP4:漏洞仍在分析中,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-SP1:漏洞仍在分析中,openEuler-24.03-LTS-SP3:漏洞仍在分析中,openEuler-24.03-LTS-SP4:漏洞仍在分析中,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-SP2:不修复-超出修复范围

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

CVE-2026-80527

影响性分析说明：
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 ]

The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.

openEuler评分:(评分和向量)
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.master:不受影响
2.openEuler-20.03-LTS-SP4:不受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响
8.openEuler-24.03-LTS-SP2:受影响
9.openEuler-24.03-LTS-SP3:受影响
10.openEuler-24.03-LTS-SP4:受影响

修复是否涉及abi变化(是/否)：
1.master:否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP3:否
4.openEuler-22.03-LTS-SP4:否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否
8.openEuler-24.03-LTS-SP2:否
9.openEuler-24.03-LTS-SP3:否
10.openEuler-24.03-LTS-SP4:否

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP3:不修复-超出修复范围
4.openEuler-22.03-LTS-SP4:暂不修复-漏洞仍在分析中
5.openEuler-24.03-LTS:不修复-超出修复范围
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:暂不修复-漏洞仍在分析中
8.openEuler-24.03-LTS-SP2:不修复-超出修复范围
9.openEuler-24.03-LTS-SP3:暂不修复-漏洞仍在分析中
10.openEuler-24.03-LTS-SP4:暂不修复-漏洞仍在分析中

@sming56_admin 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	分析项目	内容
已分析	1.影响性分析说明	In the Linux kernel, the following vulnerability has been resolved:ceph: fix hanging __ceph_get_caps() with stale mds_wantedA reader can hang forever in __ceph_get_caps() when the client nolonger holds FILE_RD, but local cap state still says that thecapability is already wanted (via mds_wanted).One way to trigger this is through MDS cap revocation. If anotherclient performs a conflicting operation, the MDS can revoke FILE_RDfrom the reader; the next read then has to reacquire FILE_RD. Ifthe cap update that should request FILE_RD never reaches the MDSafter cap->mds_wanted was raised, the reader is left holding onlynon-file caps while local mds_wanted still includes the file readcaps.In that state, try_get_cap_refs() sees need <= mds_wanted andreturns 0, so __ceph_get_caps() just waits on i_cap_wq. If the capupdate that was supposed to request FILE_RD never reaches the MDSafter cap->mds_wanted wasraised, no further request is sent and thewaiter can sleep indefinitely until unrelated cap traffic happens towake it up.The ordering issue is thatcap->mds_wantedis updated in__prep_cap() before theCEPH_MSG_CLIENT_CAPS messageis actuallyqueued for send. That makes one field serve two different meanings atonce: what this client wants, and what the client believes the MDSalready knows it wants.A proper fix would be to split those states and track whether a capupdate is actually in flight or has been observed by the MDS.However, simply moving thecap->mds_wanted assignmentlater wouldnot be sufficient: queueing the message in the messenger does notguarantee that the MDS processed that specific wanted set, andreconnect or message loss can still invalidate that assumption.Fixing that properly would require a larger rework of the cap statemachine.To allow simpler backports to stable kernels, this patch implements asimpler workaround:- stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path- make ceph_renew_caps() issue a synchronousOPENrequest 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 necessarybecause the previous test only checked whether the inode still had anyreal caps at all. That is not enough after revocation: the client canstill hold something likepLsand yet be missingFILE_RDcompletely. In that case, falling back to ceph_check_caps() is notsufficient, because it still trusts cap->mds_wantedand may resendnothing. By requiring(issued & wanted) == wanted before taking theasynchronous path, the code only uses ceph_check_caps() when thewanted capsare already actually issued. Otherwise, it sends thesynchronousOPENrenew.This preserves the existing asynchronous fast path when the wantedcaps are already issued, avoids changing cap-state semantics, andfixes the hang by guaranteeing that a stalled waiter eventuallyretries through a path that does not rely on the stalemds_wanted`state.[ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.
已分析	2.openEulerScore	7.5
已分析	3.openEulerVector	AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	master:不受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS-Next:不受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP2:受影响
已分析	5.是否涉及abi变化	master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-SP2:否
已分析	6.原因说明	master:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在,openEuler-22.03-LTS-SP4:漏洞仍在分析中,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-SP1:漏洞仍在分析中,openEuler-24.03-LTS-SP3:漏洞仍在分析中,openEuler-24.03-LTS-SP4:漏洞仍在分析中,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-SP2:不修复-超出修复范围

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

CVE-2026-80527

影响性分析说明：
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 ]

The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.

openEuler评分:(评分和向量)
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.master:不受影响
2.openEuler-20.03-LTS-SP4:不受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响
8.openEuler-24.03-LTS-SP2:受影响
9.openEuler-24.03-LTS-SP3:受影响
10.openEuler-24.03-LTS-SP4:受影响

修复是否涉及abi变化(是/否)：
1.master:否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP3:否
4.openEuler-22.03-LTS-SP4:否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否
8.openEuler-24.03-LTS-SP2:否
9.openEuler-24.03-LTS-SP3:否
10.openEuler-24.03-LTS-SP4:否

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP3:不修复-超出修复范围
4.openEuler-22.03-LTS-SP4:暂不修复-漏洞仍在分析中
5.openEuler-24.03-LTS:不修复-超出修复范围
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:暂不修复-漏洞仍在分析中
8.openEuler-24.03-LTS-SP2:不修复-超出修复范围
9.openEuler-24.03-LTS-SP3:暂不修复-漏洞仍在分析中
10.openEuler-24.03-LTS-SP4:暂不修复-漏洞仍在分析中

@sming56_admin 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	分析项目	内容
已分析	1.影响性分析说明	In the Linux kernel, the following vulnerability has been resolved:ceph: fix hanging __ceph_get_caps() with stale mds_wantedA reader can hang forever in __ceph_get_caps() when the client nolonger holds FILE_RD, but local cap state still says that thecapability is already wanted (via mds_wanted).One way to trigger this is through MDS cap revocation. If anotherclient performs a conflicting operation, the MDS can revoke FILE_RDfrom the reader; the next read then has to reacquire FILE_RD. Ifthe cap update that should request FILE_RD never reaches the MDSafter cap->mds_wanted was raised, the reader is left holding onlynon-file caps while local mds_wanted still includes the file readcaps.In that state, try_get_cap_refs() sees need <= mds_wanted andreturns 0, so __ceph_get_caps() just waits on i_cap_wq. If the capupdate that was supposed to request FILE_RD never reaches the MDSafter cap->mds_wanted wasraised, no further request is sent and thewaiter can sleep indefinitely until unrelated cap traffic happens towake it up.The ordering issue is thatcap->mds_wantedis updated in__prep_cap() before theCEPH_MSG_CLIENT_CAPS messageis actuallyqueued for send. That makes one field serve two different meanings atonce: what this client wants, and what the client believes the MDSalready knows it wants.A proper fix would be to split those states and track whether a capupdate is actually in flight or has been observed by the MDS.However, simply moving thecap->mds_wanted assignmentlater wouldnot be sufficient: queueing the message in the messenger does notguarantee that the MDS processed that specific wanted set, andreconnect or message loss can still invalidate that assumption.Fixing that properly would require a larger rework of the cap statemachine.To allow simpler backports to stable kernels, this patch implements asimpler workaround:- stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path- make ceph_renew_caps() issue a synchronousOPENrequest 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 necessarybecause the previous test only checked whether the inode still had anyreal caps at all. That is not enough after revocation: the client canstill hold something likepLsand yet be missingFILE_RDcompletely. In that case, falling back to ceph_check_caps() is notsufficient, because it still trusts cap->mds_wantedand may resendnothing. By requiring(issued & wanted) == wanted before taking theasynchronous path, the code only uses ceph_check_caps() when thewanted capsare already actually issued. Otherwise, it sends thesynchronousOPENrenew.This preserves the existing asynchronous fast path when the wantedcaps are already issued, avoids changing cap-state semantics, andfixes the hang by guaranteeing that a stalled waiter eventuallyretries through a path that does not rely on the stalemds_wanted`state.[ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.
已分析	2.openEulerScore	7.5
已分析	3.openEulerVector	AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	master:不受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS-Next:不受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP2:受影响
已分析	5.是否涉及abi变化	master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-SP2:否
已分析	6.原因说明	master:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在,openEuler-22.03-LTS-SP4:漏洞仍在分析中,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-SP1:漏洞仍在分析中,openEuler-24.03-LTS-SP3:漏洞仍在分析中,openEuler-24.03-LTS-SP4:漏洞仍在分析中,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-SP2:不修复-超出修复范围

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

CVE-2026-80527

影响性分析说明：
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 ]

The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.

openEuler评分:(评分和向量)
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.master:不受影响
2.openEuler-20.03-LTS-SP4:不受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响
8.openEuler-24.03-LTS-SP2:受影响
9.openEuler-24.03-LTS-SP3:受影响
10.openEuler-24.03-LTS-SP4:受影响

修复是否涉及abi变化(是/否)：
1.master:否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP3:否
4.openEuler-22.03-LTS-SP4:否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否
8.openEuler-24.03-LTS-SP2:否
9.openEuler-24.03-LTS-SP3:否
10.openEuler-24.03-LTS-SP4:否

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP3:不修复-超出修复范围
4.openEuler-22.03-LTS-SP4:暂不修复-漏洞仍在分析中
5.openEuler-24.03-LTS:不修复-超出修复范围
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:正常修复
8.openEuler-24.03-LTS-SP2:不修复-超出修复范围
9.openEuler-24.03-LTS-SP3:正常修复
10.openEuler-24.03-LTS-SP4:正常修复

@sming56_admin 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	分析项目	内容
已分析	1.影响性分析说明	In the Linux kernel, the following vulnerability has been resolved:ceph: fix hanging __ceph_get_caps() with stale mds_wantedA reader can hang forever in __ceph_get_caps() when the client nolonger holds FILE_RD, but local cap state still says that thecapability is already wanted (via mds_wanted).One way to trigger this is through MDS cap revocation. If anotherclient performs a conflicting operation, the MDS can revoke FILE_RDfrom the reader; the next read then has to reacquire FILE_RD. Ifthe cap update that should request FILE_RD never reaches the MDSafter cap->mds_wanted was raised, the reader is left holding onlynon-file caps while local mds_wanted still includes the file readcaps.In that state, try_get_cap_refs() sees need <= mds_wanted andreturns 0, so __ceph_get_caps() just waits on i_cap_wq. If the capupdate that was supposed to request FILE_RD never reaches the MDSafter cap->mds_wanted wasraised, no further request is sent and thewaiter can sleep indefinitely until unrelated cap traffic happens towake it up.The ordering issue is thatcap->mds_wantedis updated in__prep_cap() before theCEPH_MSG_CLIENT_CAPS messageis actuallyqueued for send. That makes one field serve two different meanings atonce: what this client wants, and what the client believes the MDSalready knows it wants.A proper fix would be to split those states and track whether a capupdate is actually in flight or has been observed by the MDS.However, simply moving thecap->mds_wanted assignmentlater wouldnot be sufficient: queueing the message in the messenger does notguarantee that the MDS processed that specific wanted set, andreconnect or message loss can still invalidate that assumption.Fixing that properly would require a larger rework of the cap statemachine.To allow simpler backports to stable kernels, this patch implements asimpler workaround:- stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path- make ceph_renew_caps() issue a synchronousOPENrequest 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 necessarybecause the previous test only checked whether the inode still had anyreal caps at all. That is not enough after revocation: the client canstill hold something likepLsand yet be missingFILE_RDcompletely. In that case, falling back to ceph_check_caps() is notsufficient, because it still trusts cap->mds_wantedand may resendnothing. By requiring(issued & wanted) == wanted before taking theasynchronous path, the code only uses ceph_check_caps() when thewanted capsare already actually issued. Otherwise, it sends thesynchronousOPENrenew.This preserves the existing asynchronous fast path when the wantedcaps are already issued, avoids changing cap-state semantics, andfixes the hang by guaranteeing that a stalled waiter eventuallyretries through a path that does not rely on the stalemds_wanted`state.[ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.
已分析	2.openEulerScore	7.5
已分析	3.openEulerVector	AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	master:不受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS-Next:不受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP2:受影响
已分析	5.是否涉及abi变化	master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-SP2:否
已分析	6.原因说明	master:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在,openEuler-22.03-LTS-SP4:漏洞仍在分析中,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-SP1:正常修复,openEuler-24.03-LTS-SP3:正常修复,openEuler-24.03-LTS-SP4:正常修复,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-SP2:不修复-超出修复范围

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

经过cve-manager解析，部分分支PR未合入，如红色字体所示：

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP4:漏洞仍在分析中
4.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS-SP1:正常修复(PR未合入)
6.openEuler-24.03-LTS-SP3:正常修复(PR未合入)
7.openEuler-24.03-LTS-SP4:正常修复(PR未合入)
8.openEuler-22.03-LTS-SP3:不修复-超出修复范围
9.openEuler-24.03-LTS:不修复-超出修复范围
10.openEuler-24.03-LTS-SP2:不修复-超出修复范围

CVE-2026-80527

影响性分析说明：
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 ]

The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.

openEuler评分:(评分和向量)
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.master:不受影响
2.openEuler-20.03-LTS-SP4:不受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响
8.openEuler-24.03-LTS-SP2:受影响
9.openEuler-24.03-LTS-SP3:受影响
10.openEuler-24.03-LTS-SP4:受影响

修复是否涉及abi变化(是/否)：
1.master:否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP3:否
4.openEuler-22.03-LTS-SP4:否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否
8.openEuler-24.03-LTS-SP2:否
9.openEuler-24.03-LTS-SP3:否
10.openEuler-24.03-LTS-SP4:否

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP3:不修复-超出修复范围
4.openEuler-22.03-LTS-SP4:正常修复
5.openEuler-24.03-LTS:不修复-超出修复范围
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:正常修复
8.openEuler-24.03-LTS-SP2:不修复-超出修复范围
9.openEuler-24.03-LTS-SP3:正常修复
10.openEuler-24.03-LTS-SP4:正常修复

@sming56_admin 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	分析项目	内容
已分析	1.影响性分析说明	In the Linux kernel, the following vulnerability has been resolved:ceph: fix hanging __ceph_get_caps() with stale mds_wantedA reader can hang forever in __ceph_get_caps() when the client nolonger holds FILE_RD, but local cap state still says that thecapability is already wanted (via mds_wanted).One way to trigger this is through MDS cap revocation. If anotherclient performs a conflicting operation, the MDS can revoke FILE_RDfrom the reader; the next read then has to reacquire FILE_RD. Ifthe cap update that should request FILE_RD never reaches the MDSafter cap->mds_wanted was raised, the reader is left holding onlynon-file caps while local mds_wanted still includes the file readcaps.In that state, try_get_cap_refs() sees need <= mds_wanted andreturns 0, so __ceph_get_caps() just waits on i_cap_wq. If the capupdate that was supposed to request FILE_RD never reaches the MDSafter cap->mds_wanted wasraised, no further request is sent and thewaiter can sleep indefinitely until unrelated cap traffic happens towake it up.The ordering issue is thatcap->mds_wantedis updated in__prep_cap() before theCEPH_MSG_CLIENT_CAPS messageis actuallyqueued for send. That makes one field serve two different meanings atonce: what this client wants, and what the client believes the MDSalready knows it wants.A proper fix would be to split those states and track whether a capupdate is actually in flight or has been observed by the MDS.However, simply moving thecap->mds_wanted assignmentlater wouldnot be sufficient: queueing the message in the messenger does notguarantee that the MDS processed that specific wanted set, andreconnect or message loss can still invalidate that assumption.Fixing that properly would require a larger rework of the cap statemachine.To allow simpler backports to stable kernels, this patch implements asimpler workaround:- stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path- make ceph_renew_caps() issue a synchronousOPENrequest 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 necessarybecause the previous test only checked whether the inode still had anyreal caps at all. That is not enough after revocation: the client canstill hold something likepLsand yet be missingFILE_RDcompletely. In that case, falling back to ceph_check_caps() is notsufficient, because it still trusts cap->mds_wantedand may resendnothing. By requiring(issued & wanted) == wanted before taking theasynchronous path, the code only uses ceph_check_caps() when thewanted capsare already actually issued. Otherwise, it sends thesynchronousOPENrenew.This preserves the existing asynchronous fast path when the wantedcaps are already issued, avoids changing cap-state semantics, andfixes the hang by guaranteeing that a stalled waiter eventuallyretries through a path that does not rely on the stalemds_wanted`state.[ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]The Linux kernel CVE team has assigned CVE-2026-80527 to this issue.
已分析	2.openEulerScore	7.5
已分析	3.openEulerVector	AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	master:不受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS-Next:不受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP2:受影响
已分析	5.是否涉及abi变化	master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-SP2:否
已分析	6.原因说明	master:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在,openEuler-22.03-LTS-SP4:正常修复,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-SP1:正常修复,openEuler-24.03-LTS-SP3:正常修复,openEuler-24.03-LTS-SP4:正常修复,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-SP2:不修复-超出修复范围

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

经过cve-manager解析，部分分支PR未合入，如红色字体所示：

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP4:正常修复(PR未合入)
4.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS-SP1:正常修复(PR未合入)
6.openEuler-24.03-LTS-SP3:正常修复(PR未合入)
7.openEuler-24.03-LTS-SP4:正常修复(PR未合入)
8.openEuler-22.03-LTS-SP3:不修复-超出修复范围
9.openEuler-24.03-LTS:不修复-超出修复范围
10.openEuler-24.03-LTS-SP2:不修复-超出修复范围

经过cve-manager解析，部分分支PR未合入，如红色字体所示：

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP4:正常修复
4.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS-SP1:正常修复(PR未合入)
6.openEuler-24.03-LTS-SP3:正常修复(PR未合入)
7.openEuler-24.03-LTS-SP4:正常修复(PR未合入)
8.openEuler-22.03-LTS-SP3:不修复-超出修复范围
9.openEuler-24.03-LTS:不修复-超出修复范围
10.openEuler-24.03-LTS-SP2:不修复-超出修复范围