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
检测到新建 CVE Issue，CVE-ID: CVE-2026-72473。
你可以通过以下两种方式使用 CVE 修复服务：
-
分支影响分析
- 在本 Issue 下评论：
/analysis_branches - 系统将自动分析各个分支是否受影响，并在本 Issue 下给出表格形式的分析结果；
- 在本 Issue 下评论：
-
在指定分支上创建 PR（修复提交）
- 在本 Issue 下按如下格式评论（
branch、name、email为必填字段，每个字段单独一行）：
- 在本 Issue 下按如下格式评论（
/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.
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.
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, @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 .
说明：补丁链接仅供初步排查参考，实际可用性请人工再次确认，补丁下载验证可使用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-72473
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Decouple req recycling from RPC completion
rl_kref formerly served two distinct lifetimes through a single
refcount: it gated when a Reply could wake its RPC task, and it
gated when an rpcrdma_req could return to its free pool. The
marshal path took the Send-side reference only when SGEs needed
DMA-unmap (sc_unmap_count > 0), which made a Send carrying only
pre-registered buffers an exception: the Reply handler dropped
rl_kref from 1 to 0 and freed the req while the HCA might still
be DMA-reading from its send buffer.
Give rl_kref a narrower job. The RPC layer takes one reference
when slot allocation hands a req out. rpcrdma_prepare_send_sges()
takes a Send-side reference unconditionally after WR preparation
succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop
the RPC-layer reference; rpcrdma_sendctx_unmap() drops the
Send-side reference. The req returns to its free pool only after
both owners have signed off.
The existing kref_init(&req->rl_kref) call in
rpcrdma_prepare_send_sges() is removed. Initialization moves to
the slot-allocation paths (xprt_rdma_alloc_slot and
rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref
before the req returns to a free pool. A re-init in the marshal
path would discard the RPC-layer reference that already exists
on entry.
Three invariants follow:
-
Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1.
xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the
backlog-wake branch in xprt_rdma_alloc_slot() each kref_init
rl_kref before publishing the req. Without this invariant,
an RPC task that aborts between slot allocation and marshal
(gss_refresh failure or signal during call_connect, for
example) would drive xprt_release() ->
xprt_rdma_free_slot() -> kref_put against a refcount of
zero, saturating refcount_t and stranding the slot. -
The Send-side reference is taken only after WR prep
succeeds. A mapping failure in rpcrdma_prepare_send_sges()
runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx
and clears sc_req without touching rl_kref. The sendctx
ring walks in rpcrdma_sendctx_put_locked() and
rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,
so a burst of -EIO marshal failures cannot hold reqs off
rb_send_bufs. -
The release callback re-arms rl_kref so the next consumer
enters with the invariant satisfied.
Replies now complete the RPC directly. rpcrdma_reply_handler()
calls rpcrdma_complete_rqst() in place of kref_put on the
non-LocalInv branch. The LocalInv branch already completes the
RPC from frwr_unmap_async() and is unaffected.
Because Send-side references can now outlive RPC completion,
connection teardown drains sendctx entries whose unsignaled
Sends never had a later signaled completion to walk the ring.
rpcrdma_sendctxs_destroy() walks the active range and runs
rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req
before the request buffers are reset, and is moved ahead of
rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs
are still in their pre-reset state when the Send-side refs are
released.
The drain creates a teardown-ordering hazard on the backchannel
path. With the new lifetime, releasing a bc_prealloc req from
rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect
in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has
already emptied bc_pa_list, so the drained reqs would otherwise
leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)
a second time after the disconnect to reclaim them.
The Linux kernel CVE team has assigned CVE-2026-72473 to this issue.
openEuler评分:(评分和向量)
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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:暂不修复-漏洞仍在分析中
@hu-chunzhi 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态 | 分析项目 | 内容 |
|---|---|---|
| 已分析 | 1.影响性分析说明 | In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decouple req recycling from RPC completionrl_kref formerly served two distinct lifetimes through a singlerefcount: it gated when a Reply could wake its RPC task, and itgated when an rpcrdma_req could return to its free pool. Themarshal path took the Send-side reference only when SGEs neededDMA-unmap (sc_unmap_count > 0), which made a Send carrying onlypre-registered buffers an exception: the Reply handler droppedrl_kref from 1 to 0 and freed the req while the HCA might stillbe DMA-reading from its send buffer.Give rl_kref a narrower job. The RPC layer takes one referencewhen slot allocation hands a req out. rpcrdma_prepare_send_sges()takes a Send-side reference unconditionally after WR preparationsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() dropthe RPC-layer reference; rpcrdma_sendctx_unmap() drops theSend-side reference. The req returns to its free pool only afterboth owners have signed off.The existing kref_init(&req->rl_kref) call inrpcrdma_prepare_send_sges() is removed. Initialization moves tothe slot-allocation paths (xprt_rdma_alloc_slot andrpcrdma_bc_rqst_get), and the release callback re-arms rl_krefbefore the req returns to a free pool. A re-init in the marshalpath would discard the RPC-layer reference that already existson entry.Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.Replies now complete the RPC directly. rpcrdma_reply_handler()calls rpcrdma_complete_rqst() in place of kref_put on thenon-LocalInv branch. The LocalInv branch already completes theRPC from frwr_unmap_async() and is unaffected.Because Send-side references can now outlive RPC completion,connection teardown drains sendctx entries whose unsignaledSends never had a later signaled completion to walk the ring.rpcrdma_sendctxs_destroy() walks the active range and runsrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_reqbefore the request buffers are reset, and is moved ahead ofrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqsare still in their pre-reset state when the Send-side refs arereleased.The drain creates a teardown-ordering hazard on the backchannelpath. With the new lifetime, releasing a bc_prealloc req fromrpcrdma_req_release() re-adds it to bc_pa_list. The disconnectin xprt_rdma_destroy() runs after xprt_destroy_backchannel() hasalready emptied bc_pa_list, so the drained reqs would otherwiseleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)a second time after the disconnect to reclaim them.The Linux kernel CVE team has assigned CVE-2026-72473 to this issue. |
| 已分析 | 2.openEulerScore | 9.8 |
| 已分析 | 3.openEulerVector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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-72473
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Decouple req recycling from RPC completion
rl_kref formerly served two distinct lifetimes through a single
refcount: it gated when a Reply could wake its RPC task, and it
gated when an rpcrdma_req could return to its free pool. The
marshal path took the Send-side reference only when SGEs needed
DMA-unmap (sc_unmap_count > 0), which made a Send carrying only
pre-registered buffers an exception: the Reply handler dropped
rl_kref from 1 to 0 and freed the req while the HCA might still
be DMA-reading from its send buffer.
Give rl_kref a narrower job. The RPC layer takes one reference
when slot allocation hands a req out. rpcrdma_prepare_send_sges()
takes a Send-side reference unconditionally after WR preparation
succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop
the RPC-layer reference; rpcrdma_sendctx_unmap() drops the
Send-side reference. The req returns to its free pool only after
both owners have signed off.
The existing kref_init(&req->rl_kref) call in
rpcrdma_prepare_send_sges() is removed. Initialization moves to
the slot-allocation paths (xprt_rdma_alloc_slot and
rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref
before the req returns to a free pool. A re-init in the marshal
path would discard the RPC-layer reference that already exists
on entry.
Three invariants follow:
-
Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1.
xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the
backlog-wake branch in xprt_rdma_alloc_slot() each kref_init
rl_kref before publishing the req. Without this invariant,
an RPC task that aborts between slot allocation and marshal
(gss_refresh failure or signal during call_connect, for
example) would drive xprt_release() ->
xprt_rdma_free_slot() -> kref_put against a refcount of
zero, saturating refcount_t and stranding the slot. -
The Send-side reference is taken only after WR prep
succeeds. A mapping failure in rpcrdma_prepare_send_sges()
runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx
and clears sc_req without touching rl_kref. The sendctx
ring walks in rpcrdma_sendctx_put_locked() and
rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,
so a burst of -EIO marshal failures cannot hold reqs off
rb_send_bufs. -
The release callback re-arms rl_kref so the next consumer
enters with the invariant satisfied.
Replies now complete the RPC directly. rpcrdma_reply_handler()
calls rpcrdma_complete_rqst() in place of kref_put on the
non-LocalInv branch. The LocalInv branch already completes the
RPC from frwr_unmap_async() and is unaffected.
Because Send-side references can now outlive RPC completion,
connection teardown drains sendctx entries whose unsignaled
Sends never had a later signaled completion to walk the ring.
rpcrdma_sendctxs_destroy() walks the active range and runs
rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req
before the request buffers are reset, and is moved ahead of
rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs
are still in their pre-reset state when the Send-side refs are
released.
The drain creates a teardown-ordering hazard on the backchannel
path. With the new lifetime, releasing a bc_prealloc req from
rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect
in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has
already emptied bc_pa_list, so the drained reqs would otherwise
leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)
a second time after the disconnect to reclaim them.
The Linux kernel CVE team has assigned CVE-2026-72473 to this issue.
openEuler评分:(评分和向量)
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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:暂不修复-漏洞仍在分析中
@hu-chunzhi 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态 | 分析项目 | 内容 |
|---|---|---|
| 已分析 | 1.影响性分析说明 | In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decouple req recycling from RPC completionrl_kref formerly served two distinct lifetimes through a singlerefcount: it gated when a Reply could wake its RPC task, and itgated when an rpcrdma_req could return to its free pool. Themarshal path took the Send-side reference only when SGEs neededDMA-unmap (sc_unmap_count > 0), which made a Send carrying onlypre-registered buffers an exception: the Reply handler droppedrl_kref from 1 to 0 and freed the req while the HCA might stillbe DMA-reading from its send buffer.Give rl_kref a narrower job. The RPC layer takes one referencewhen slot allocation hands a req out. rpcrdma_prepare_send_sges()takes a Send-side reference unconditionally after WR preparationsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() dropthe RPC-layer reference; rpcrdma_sendctx_unmap() drops theSend-side reference. The req returns to its free pool only afterboth owners have signed off.The existing kref_init(&req->rl_kref) call inrpcrdma_prepare_send_sges() is removed. Initialization moves tothe slot-allocation paths (xprt_rdma_alloc_slot andrpcrdma_bc_rqst_get), and the release callback re-arms rl_krefbefore the req returns to a free pool. A re-init in the marshalpath would discard the RPC-layer reference that already existson entry.Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.Replies now complete the RPC directly. rpcrdma_reply_handler()calls rpcrdma_complete_rqst() in place of kref_put on thenon-LocalInv branch. The LocalInv branch already completes theRPC from frwr_unmap_async() and is unaffected.Because Send-side references can now outlive RPC completion,connection teardown drains sendctx entries whose unsignaledSends never had a later signaled completion to walk the ring.rpcrdma_sendctxs_destroy() walks the active range and runsrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_reqbefore the request buffers are reset, and is moved ahead ofrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqsare still in their pre-reset state when the Send-side refs arereleased.The drain creates a teardown-ordering hazard on the backchannelpath. With the new lifetime, releasing a bc_prealloc req fromrpcrdma_req_release() re-adds it to bc_pa_list. The disconnectin xprt_rdma_destroy() runs after xprt_destroy_backchannel() hasalready emptied bc_pa_list, so the drained reqs would otherwiseleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)a second time after the disconnect to reclaim them.The Linux kernel CVE team has assigned CVE-2026-72473 to this issue. |
| 已分析 | 2.openEulerScore | 9.8 |
| 已分析 | 3.openEulerVector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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-72473
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Decouple req recycling from RPC completion
rl_kref formerly served two distinct lifetimes through a single
refcount: it gated when a Reply could wake its RPC task, and it
gated when an rpcrdma_req could return to its free pool. The
marshal path took the Send-side reference only when SGEs needed
DMA-unmap (sc_unmap_count > 0), which made a Send carrying only
pre-registered buffers an exception: the Reply handler dropped
rl_kref from 1 to 0 and freed the req while the HCA might still
be DMA-reading from its send buffer.
Give rl_kref a narrower job. The RPC layer takes one reference
when slot allocation hands a req out. rpcrdma_prepare_send_sges()
takes a Send-side reference unconditionally after WR preparation
succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop
the RPC-layer reference; rpcrdma_sendctx_unmap() drops the
Send-side reference. The req returns to its free pool only after
both owners have signed off.
The existing kref_init(&req->rl_kref) call in
rpcrdma_prepare_send_sges() is removed. Initialization moves to
the slot-allocation paths (xprt_rdma_alloc_slot and
rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref
before the req returns to a free pool. A re-init in the marshal
path would discard the RPC-layer reference that already exists
on entry.
Three invariants follow:
-
Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1.
xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the
backlog-wake branch in xprt_rdma_alloc_slot() each kref_init
rl_kref before publishing the req. Without this invariant,
an RPC task that aborts between slot allocation and marshal
(gss_refresh failure or signal during call_connect, for
example) would drive xprt_release() ->
xprt_rdma_free_slot() -> kref_put against a refcount of
zero, saturating refcount_t and stranding the slot. -
The Send-side reference is taken only after WR prep
succeeds. A mapping failure in rpcrdma_prepare_send_sges()
runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx
and clears sc_req without touching rl_kref. The sendctx
ring walks in rpcrdma_sendctx_put_locked() and
rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,
so a burst of -EIO marshal failures cannot hold reqs off
rb_send_bufs. -
The release callback re-arms rl_kref so the next consumer
enters with the invariant satisfied.
Replies now complete the RPC directly. rpcrdma_reply_handler()
calls rpcrdma_complete_rqst() in place of kref_put on the
non-LocalInv branch. The LocalInv branch already completes the
RPC from frwr_unmap_async() and is unaffected.
Because Send-side references can now outlive RPC completion,
connection teardown drains sendctx entries whose unsignaled
Sends never had a later signaled completion to walk the ring.
rpcrdma_sendctxs_destroy() walks the active range and runs
rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req
before the request buffers are reset, and is moved ahead of
rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs
are still in their pre-reset state when the Send-side refs are
released.
The drain creates a teardown-ordering hazard on the backchannel
path. With the new lifetime, releasing a bc_prealloc req from
rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect
in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has
already emptied bc_pa_list, so the drained reqs would otherwise
leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)
a second time after the disconnect to reclaim them.
The Linux kernel CVE team has assigned CVE-2026-72473 to this issue.
openEuler评分:(评分和向量)
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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:暂不修复-漏洞仍在分析中
@hu-chunzhi 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态 | 分析项目 | 内容 |
|---|---|---|
| 已分析 | 1.影响性分析说明 | In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decouple req recycling from RPC completionrl_kref formerly served two distinct lifetimes through a singlerefcount: it gated when a Reply could wake its RPC task, and itgated when an rpcrdma_req could return to its free pool. Themarshal path took the Send-side reference only when SGEs neededDMA-unmap (sc_unmap_count > 0), which made a Send carrying onlypre-registered buffers an exception: the Reply handler droppedrl_kref from 1 to 0 and freed the req while the HCA might stillbe DMA-reading from its send buffer.Give rl_kref a narrower job. The RPC layer takes one referencewhen slot allocation hands a req out. rpcrdma_prepare_send_sges()takes a Send-side reference unconditionally after WR preparationsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() dropthe RPC-layer reference; rpcrdma_sendctx_unmap() drops theSend-side reference. The req returns to its free pool only afterboth owners have signed off.The existing kref_init(&req->rl_kref) call inrpcrdma_prepare_send_sges() is removed. Initialization moves tothe slot-allocation paths (xprt_rdma_alloc_slot andrpcrdma_bc_rqst_get), and the release callback re-arms rl_krefbefore the req returns to a free pool. A re-init in the marshalpath would discard the RPC-layer reference that already existson entry.Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.Replies now complete the RPC directly. rpcrdma_reply_handler()calls rpcrdma_complete_rqst() in place of kref_put on thenon-LocalInv branch. The LocalInv branch already completes theRPC from frwr_unmap_async() and is unaffected.Because Send-side references can now outlive RPC completion,connection teardown drains sendctx entries whose unsignaledSends never had a later signaled completion to walk the ring.rpcrdma_sendctxs_destroy() walks the active range and runsrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_reqbefore the request buffers are reset, and is moved ahead ofrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqsare still in their pre-reset state when the Send-side refs arereleased.The drain creates a teardown-ordering hazard on the backchannelpath. With the new lifetime, releasing a bc_prealloc req fromrpcrdma_req_release() re-adds it to bc_pa_list. The disconnectin xprt_rdma_destroy() runs after xprt_destroy_backchannel() hasalready emptied bc_pa_list, so the drained reqs would otherwiseleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)a second time after the disconnect to reclaim them.The Linux kernel CVE team has assigned CVE-2026-72473 to this issue. |
| 已分析 | 2.openEulerScore | 9.8 |
| 已分析 | 3.openEulerVector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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-72473
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Decouple req recycling from RPC completion
rl_kref formerly served two distinct lifetimes through a single
refcount: it gated when a Reply could wake its RPC task, and it
gated when an rpcrdma_req could return to its free pool. The
marshal path took the Send-side reference only when SGEs needed
DMA-unmap (sc_unmap_count > 0), which made a Send carrying only
pre-registered buffers an exception: the Reply handler dropped
rl_kref from 1 to 0 and freed the req while the HCA might still
be DMA-reading from its send buffer.
Give rl_kref a narrower job. The RPC layer takes one reference
when slot allocation hands a req out. rpcrdma_prepare_send_sges()
takes a Send-side reference unconditionally after WR preparation
succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop
the RPC-layer reference; rpcrdma_sendctx_unmap() drops the
Send-side reference. The req returns to its free pool only after
both owners have signed off.
The existing kref_init(&req->rl_kref) call in
rpcrdma_prepare_send_sges() is removed. Initialization moves to
the slot-allocation paths (xprt_rdma_alloc_slot and
rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref
before the req returns to a free pool. A re-init in the marshal
path would discard the RPC-layer reference that already exists
on entry.
Three invariants follow:
-
Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1.
xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the
backlog-wake branch in xprt_rdma_alloc_slot() each kref_init
rl_kref before publishing the req. Without this invariant,
an RPC task that aborts between slot allocation and marshal
(gss_refresh failure or signal during call_connect, for
example) would drive xprt_release() ->
xprt_rdma_free_slot() -> kref_put against a refcount of
zero, saturating refcount_t and stranding the slot. -
The Send-side reference is taken only after WR prep
succeeds. A mapping failure in rpcrdma_prepare_send_sges()
runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx
and clears sc_req without touching rl_kref. The sendctx
ring walks in rpcrdma_sendctx_put_locked() and
rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,
so a burst of -EIO marshal failures cannot hold reqs off
rb_send_bufs. -
The release callback re-arms rl_kref so the next consumer
enters with the invariant satisfied.
Replies now complete the RPC directly. rpcrdma_reply_handler()
calls rpcrdma_complete_rqst() in place of kref_put on the
non-LocalInv branch. The LocalInv branch already completes the
RPC from frwr_unmap_async() and is unaffected.
Because Send-side references can now outlive RPC completion,
connection teardown drains sendctx entries whose unsignaled
Sends never had a later signaled completion to walk the ring.
rpcrdma_sendctxs_destroy() walks the active range and runs
rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req
before the request buffers are reset, and is moved ahead of
rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs
are still in their pre-reset state when the Send-side refs are
released.
The drain creates a teardown-ordering hazard on the backchannel
path. With the new lifetime, releasing a bc_prealloc req from
rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect
in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has
already emptied bc_pa_list, so the drained reqs would otherwise
leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)
a second time after the disconnect to reclaim them.
The Linux kernel CVE team has assigned CVE-2026-72473 to this issue.
openEuler评分:(评分和向量)
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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:正常修复
@hu-chunzhi 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态 | 分析项目 | 内容 |
|---|---|---|
| 已分析 | 1.影响性分析说明 | In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decouple req recycling from RPC completionrl_kref formerly served two distinct lifetimes through a singlerefcount: it gated when a Reply could wake its RPC task, and itgated when an rpcrdma_req could return to its free pool. Themarshal path took the Send-side reference only when SGEs neededDMA-unmap (sc_unmap_count > 0), which made a Send carrying onlypre-registered buffers an exception: the Reply handler droppedrl_kref from 1 to 0 and freed the req while the HCA might stillbe DMA-reading from its send buffer.Give rl_kref a narrower job. The RPC layer takes one referencewhen slot allocation hands a req out. rpcrdma_prepare_send_sges()takes a Send-side reference unconditionally after WR preparationsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() dropthe RPC-layer reference; rpcrdma_sendctx_unmap() drops theSend-side reference. The req returns to its free pool only afterboth owners have signed off.The existing kref_init(&req->rl_kref) call inrpcrdma_prepare_send_sges() is removed. Initialization moves tothe slot-allocation paths (xprt_rdma_alloc_slot andrpcrdma_bc_rqst_get), and the release callback re-arms rl_krefbefore the req returns to a free pool. A re-init in the marshalpath would discard the RPC-layer reference that already existson entry.Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.Replies now complete the RPC directly. rpcrdma_reply_handler()calls rpcrdma_complete_rqst() in place of kref_put on thenon-LocalInv branch. The LocalInv branch already completes theRPC from frwr_unmap_async() and is unaffected.Because Send-side references can now outlive RPC completion,connection teardown drains sendctx entries whose unsignaledSends never had a later signaled completion to walk the ring.rpcrdma_sendctxs_destroy() walks the active range and runsrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_reqbefore the request buffers are reset, and is moved ahead ofrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqsare still in their pre-reset state when the Send-side refs arereleased.The drain creates a teardown-ordering hazard on the backchannelpath. With the new lifetime, releasing a bc_prealloc req fromrpcrdma_req_release() re-adds it to bc_pa_list. The disconnectin xprt_rdma_destroy() runs after xprt_destroy_backchannel() hasalready emptied bc_pa_list, so the drained reqs would otherwiseleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)a second time after the disconnect to reclaim them.The Linux kernel CVE team has assigned CVE-2026-72473 to this issue. |
| 已分析 | 2.openEulerScore | 9.8 |
| 已分析 | 3.openEulerVector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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:不修复-超出修复范围
/check-issue
@hu-chunzhi 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态 | 分析项目 | 内容 |
|---|---|---|
| 已分析 | 1.影响性分析说明 | In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decouple req recycling from RPC completionrl_kref formerly served two distinct lifetimes through a singlerefcount: it gated when a Reply could wake its RPC task, and itgated when an rpcrdma_req could return to its free pool. Themarshal path took the Send-side reference only when SGEs neededDMA-unmap (sc_unmap_count > 0), which made a Send carrying onlypre-registered buffers an exception: the Reply handler droppedrl_kref from 1 to 0 and freed the req while the HCA might stillbe DMA-reading from its send buffer.Give rl_kref a narrower job. The RPC layer takes one referencewhen slot allocation hands a req out. rpcrdma_prepare_send_sges()takes a Send-side reference unconditionally after WR preparationsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() dropthe RPC-layer reference; rpcrdma_sendctx_unmap() drops theSend-side reference. The req returns to its free pool only afterboth owners have signed off.The existing kref_init(&req->rl_kref) call inrpcrdma_prepare_send_sges() is removed. Initialization moves tothe slot-allocation paths (xprt_rdma_alloc_slot andrpcrdma_bc_rqst_get), and the release callback re-arms rl_krefbefore the req returns to a free pool. A re-init in the marshalpath would discard the RPC-layer reference that already existson entry.Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.Replies now complete the RPC directly. rpcrdma_reply_handler()calls rpcrdma_complete_rqst() in place of kref_put on thenon-LocalInv branch. The LocalInv branch already completes theRPC from frwr_unmap_async() and is unaffected.Because Send-side references can now outlive RPC completion,connection teardown drains sendctx entries whose unsignaledSends never had a later signaled completion to walk the ring.rpcrdma_sendctxs_destroy() walks the active range and runsrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_reqbefore the request buffers are reset, and is moved ahead ofrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqsare still in their pre-reset state when the Send-side refs arereleased.The drain creates a teardown-ordering hazard on the backchannelpath. With the new lifetime, releasing a bc_prealloc req fromrpcrdma_req_release() re-adds it to bc_pa_list. The disconnectin xprt_rdma_destroy() runs after xprt_destroy_backchannel() hasalready emptied bc_pa_list, so the drained reqs would otherwiseleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)a second time after the disconnect to reclaim them.The Linux kernel CVE team has assigned CVE-2026-72473 to this issue. |
| 已分析 | 2.openEulerScore | 9.8 |
| 已分析 | 3.openEulerVector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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-72473
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.12.33,6.18.18,6.4.0,6.6.0
CVSS评分：
BaseScore：9.8 Critical
Vector：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
漏洞简述：
In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decouple req recycling from RPC completionrl_kref formerly served two distinct lifetimes through a singlerefcount: it gated when a Reply could wake its RPC task, and itgated when an rpcrdma_req could return to its free pool. Themarshal path took the Send-side reference only when SGEs neededDMA-unmap (sc_unmap_count > 0), which made a Send carrying onlypre-registered buffers an exception: the Reply handler droppedrl_kref from 1 to 0 and freed the req while the HCA might stillbe DMA-reading from its send buffer.Give rl_kref a narrower job. The RPC layer takes one referencewhen slot allocation hands a req out. rpcrdma_prepare_send_sges()takes a Send-side reference unconditionally after WR preparationsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() dropthe RPC-layer reference; rpcrdma_sendctx_unmap() drops theSend-side reference. The req returns to its free pool only afterboth owners have signed off.The existing kref_init(&req->rl_kref) call inrpcrdma_prepare_send_sges() is removed. Initialization moves tothe slot-allocation paths (xprt_rdma_alloc_slot andrpcrdma_bc_rqst_get), and the release callback re-arms rl_krefbefore the req returns to a free pool. A re-init in the marshalpath would discard the RPC-layer reference that already existson entry.Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.Replies now complete the RPC directly. rpcrdma_reply_handler()calls rpcrdma_complete_rqst() in place of kref_put on thenon-LocalInv branch. The LocalInv branch already completes theRPC from frwr_unmap_async() and is unaffected.Because Send-side references can now outlive RPC completion,connection teardown drains sendctx entries whose unsignaledSends never had a later signaled completion to walk the ring.rpcrdma_sendctxs_destroy() walks the active range and runsrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_reqbefore the request buffers are reset, and is moved ahead ofrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqsare still in their pre-reset state when the Send-side refs arereleased.The drain creates a teardown-ordering hazard on the backchannelpath. With the new lifetime, releasing a bc_prealloc req fromrpcrdma_req_release() re-adds it to bc_pa_list. The disconnectin xprt_rdma_destroy() runs after xprt_destroy_backchannel() hasalready emptied bc_pa_list, so the drained reqs would otherwiseleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)a second time after the disconnect to reclaim them.
漏洞公开时间：2026-08-15 14:22:21
漏洞创建时间：2026-08-17 21:53:00
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2026-72473
更多参考(点击展开)
漏洞分析指导链接：
https://atomgit.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
七彩瞬析开源风险感知平台
漏洞补丁信息：
详情(点击展开)
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decouple req recycling from RPC completionrl_kref formerly served two distinct lifetimes through a singlerefcount: it gated when a Reply could wake its RPC task, and itgated when an rpcrdma_req could return to its free pool. Themarshal path took the Send-side reference only when SGEs neededDMA-unmap (sc_unmap_count > 0), which made a Send carrying onlypre-registered buffers an exception: the Reply handler droppedrl_kref from 1 to 0 and freed the req while the HCA might stillbe DMA-reading from its send buffer.Give rl_kref a narrower job. The RPC layer takes one referencewhen slot allocation hands a req out. rpcrdma_prepare_send_sges()takes a Send-side reference unconditionally after WR preparationsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() dropthe RPC-layer reference; rpcrdma_sendctx_unmap() drops theSend-side reference. The req returns to its free pool only afterboth owners have signed off.The existing kref_init(&req->rl_kref) call inrpcrdma_prepare_send_sges() is removed. Initialization moves tothe slot-allocation paths (xprt_rdma_alloc_slot andrpcrdma_bc_rqst_get), and the release callback re-arms rl_krefbefore the req returns to a free pool. A re-init in the marshalpath would discard the RPC-layer reference that already existson entry.Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.Replies now complete the RPC directly. rpcrdma_reply_handler()calls rpcrdma_complete_rqst() in place of kref_put on thenon-LocalInv branch. The LocalInv branch already completes theRPC from frwr_unmap_async() and is unaffected.Because Send-side references can now outlive RPC completion,connection teardown drains sendctx entries whose unsignaledSends never had a later signaled completion to walk the ring.rpcrdma_sendctxs_destroy() walks the active range and runsrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_reqbefore the request buffers are reset, and is moved ahead ofrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqsare still in their pre-reset state when the Send-side refs arereleased.The drain creates a teardown-ordering hazard on the backchannelpath. With the new lifetime, releasing a bc_prealloc req fromrpcrdma_req_release() re-adds it to bc_pa_list. The disconnectin xprt_rdma_destroy() runs after xprt_destroy_backchannel() hasalready emptied bc_pa_list, so the drained reqs would otherwiseleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)a second time after the disconnect to reclaim them.The Linux kernel CVE team has assigned CVE-2026-72473 to this issue.
openEuler评分：
9.8
Vector：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
受影响版本排查(受影响/不受影响)：
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):受影响
8.openEuler-22.03-LTS-SP3(5.10.0):受影响
9.openEuler-24.03-LTS(6.6.0):受影响
10.openEuler-24.03-LTS-SP2(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):否
8.openEuler-22.03-LTS-SP3(5.10.0):否
9.openEuler-24.03-LTS(6.6.0):否
10.openEuler-24.03-LTS-SP2(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):正常修复
8.openEuler-22.03-LTS-SP3(5.10.0):不修复-超出修复范围
9.openEuler-24.03-LTS(6.6.0):不修复-超出修复范围
10.openEuler-24.03-LTS-SP2(6.6.0):不修复-超出修复范围