检测到新建 CVE Issue，CVE-ID: CVE-2026-99077。
你可以通过以下两种方式使用 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；不填时默认使用opencode；
系统会根据上述信息自动在指定分支上创建 PR，并在本 Issue 下反馈结果。
provided by DevStation.
openeuler-ci-botWelcome To openEuler Community
Hey @zhangxiaoxv , 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, @chenxiaosonggitcode, @chiqijun, @chizl, @chriszjh, @duanqiangwen, @eingesch, @fangfeng123, @fanghaiqinghw, @gang_he, @gaojuxin09, @gouhao2022, @guohaocs2c, @guzitao, @hanjunguo, @hanliyang, @hellotcc, @henryze, @hewanhan, @hjx_gitff, @hongwu-wang, @howard_lu, @htforge, @hu-chunzhi, @hunan4222, @hygmm, @jackknight, @jerry_lilijun, @jiayi0118, @junlong-zheng, @juntianlinux, @kailiu42, @kaitiandu, @kazero00, @kevinzhu1, @kile2009, @klmengkd, @koishimind, @kongzizaixian, @kunlun_spurs, @kylin-mayukun, @leap-io, @leap-zjke, @leoliu-oc, @li-huisong, @linan888, @linyuexie1, @linyunsheng, @liulongfang, @liyihang0226, @lostway1, @lujialin2, @mao-hongbo, @markyuan4ta21, @mawupeng, @mingqian218472, @mingrui-liu, @mufengyan, @nebulamatrix_rdma, @peterpangogogo, @pigalsofine, @raoxu-deepin, @robinorg, @rock_hw, @sageDriver, @sanglipeng, @shu-shengming, @shuaijiakun, @sinat_17738335, @siyanteng, @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, @zhangguodong11, @zhangyi089, @zhujianwei001, @zichengqu, @zouyipeng, @zqiao216 .
openEuler评分:(评分和向量)
7.4
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
/get-cve
@yangwei999 CVE信息从NVD同步成功, 稍后请重新加载页面.
openeuler-ci-botsource: @hulk-ci-bot
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:
ipv4: udp: Create exceptions before socket matching
Currently, when ICMP Fragmentation Needed and Redirect Message packets
are locally delivered and quote a UDP packet, a FIB nexthop exception
(FNHE) is only created if the kernel can match the UDP packet to an
existing socket.
This behavior allows off-path attackers to conduct a side-channel attack
on the FNHE cache in order to discover the ephemeral port used by a
connected UDP socket.
Commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in
fnhe_hashfun()") and commit 67d6d681e15b ("ipv4: make exception cache
less predictible") tried to mitigate such attacks by making it harder
for attackers to discover hash collisions in the FNHE cache and by
randomizing the number of exceptions a hash bucket can hold,
respectively. Unfortunately, both of the mitigations can be bypassed.
Instead, mitigate such attacks by always creating a FNHE, even before
trying to find a matching socket. Do that by calling ipv4_update_pmtu()
and ipv4_redirect(), the helpers used when the quoted packet did not
originate from a socket.
This means that guesses (right or wrong) from an off-path attacker will
always result in a FNHE being created or updated in the cache that the
attacker can observe.
Pass an oif of 0, in a similar fashion to icmp_err(). This is also the
oif used by the socket path for sockets that are not bound to a device.
Note that this does not allow attackers to create FNHEs that they could
not create before, as both helpers can already be reached with little to
no validation. For example, by sending an ICMP error that quotes an ICMP
Echo Reply or one that quotes a UDP source port that matches a wildcard
socket.
Also note that in the good case (matched socket) the above scheme comes
at the cost of an extra route lookup, as the no socket helpers perform
their own lookup before the one performed by ipv4_sk_update_pmtu() /
ipv4_sk_redirect(). When the two resolve to different nexthops, it also
results in two exceptions being created for the same destination IP. One
in the FNHE cache of the nexthop resolved by the no socket helpers and
another in the FNHE cache of the nexthop used by the socket.
openEuler评分：
7.4
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
受影响版本排查(受影响/不受影响)：
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:暂不修复-漏洞仍在分析中
@ 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态 | 分析项目 | 内容 |
|---|---|---|
| 已分析 | 1.影响性分析说明 | In the Linux kernel, the following vulnerability has been resolved:ipv4: udp: Create exceptions before socket matchingCurrently, when ICMP Fragmentation Needed and Redirect Message packetsare locally delivered and quote a UDP packet, a FIB nexthop exception(FNHE) is only created if the kernel can match the UDP packet to anexisting socket.This behavior allows off-path attackers to conduct a side-channel attackon the FNHE cache in order to discover the ephemeral port used by aconnected UDP socket.Commit 6457378fe796 ("ipv4: use siphash instead of Jenkins infnhe_hashfun()") and commit 67d6d681e15b ("ipv4: make exception cacheless predictible") tried to mitigate such attacks by making it harderfor attackers to discover hash collisions in the FNHE cache and byrandomizing the number of exceptions a hash bucket can hold,respectively. Unfortunately, both of the mitigations can be bypassed.Instead, mitigate such attacks by always creating a FNHE, even beforetrying to find a matching socket. Do that by calling ipv4_update_pmtu()and ipv4_redirect(), the helpers used when the quoted packet did notoriginate from a socket.This means that guesses (right or wrong) from an off-path attacker willalways result in a FNHE being created or updated in the cache that theattacker can observe.Pass an oif of 0, in a similar fashion to icmp_err(). This is also theoif used by the socket path for sockets that are not bound to a device.Note that this does not allow attackers to create FNHEs that they couldnot create before, as both helpers can already be reached with little tono validation. For example, by sending an ICMP error that quotes an ICMPEcho Reply or one that quotes a UDP source port that matches a wildcardsocket.Also note that in the good case (matched socket) the above scheme comesat the cost of an extra route lookup, as the no socket helpers performtheir own lookup before the one performed by ipv4_sk_update_pmtu() /ipv4_sk_redirect(). When the two resolve to different nexthops, it alsoresults in two exceptions being created for the same destination IP. Onein the FNHE cache of the nexthop resolved by the no socket helpers andanother in the FNHE cache of the nexthop used by the socket. |
| 已分析 | 2.openEulerScore | 7.4 |
| 已分析 | 3.openEulerVector | AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N |
| 已分析 | 4.受影响版本排查 | master:不受影响,openEuler-20.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-Next:不受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP2:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响 |
| 已分析 | 5.是否涉及abi变化 | master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP2:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否 |
| 已分析 | 6.原因说明 | master:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:暂不修复-漏洞仍在分析中,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-22.03-LTS-SP4:不修复-超出修复范围,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-SP1:暂不修复-漏洞仍在分析中,openEuler-24.03-LTS-SP2:不修复-超出修复范围,openEuler-24.03-LTS-SP3:暂不修复-漏洞仍在分析中,openEuler-24.03-LTS-SP4:暂不修复-漏洞仍在分析中 |
请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.
一、漏洞信息
漏洞编号：CVE-2026-99077
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.90,5.10.0,6.1.19,6.18.40,6.18.56,6.4.0,6.6.0
CVSS评分：
BaseScore：N/A None
Vector：
漏洞简述：
In the Linux kernel, the following vulnerability has been resolved:ipv4: udp: Create exceptions before socket matchingCurrently, when ICMP Fragmentation Needed and Redirect Message packetsare locally delivered and quote a UDP packet, a FIB nexthop exception(FNHE) is only created if the kernel can match the UDP packet to anexisting socket.This behavior allows off-path attackers to conduct a side-channel attackon the FNHE cache in order to discover the ephemeral port used by aconnected UDP socket.Commit 6457378fe796 ( ipv4: use siphash instead of Jenkins infnhe_hashfun() ) and commit 67d6d681e15b ( ipv4: make exception cacheless predictible ) tried to mitigate such attacks by making it harderfor attackers to discover hash collisions in the FNHE cache and byrandomizing the number of exceptions a hash bucket can hold,respectively. Unfortunately, both of the mitigations can be bypassed.Instead, mitigate such attacks by always creating a FNHE, even beforetrying to find a matching socket. Do that by calling ipv4_update_pmtu()and ipv4_redirect(), the helpers used when the quoted packet did notoriginate from a socket.This means that guesses (right or wrong) from an off-path attacker willalways result in a FNHE being created or updated in the cache that theattacker can observe.Pass an oif of 0, in a similar fashion to icmp_err(). This is also theoif used by the socket path for sockets that are not bound to a device.Note that this does not allow attackers to create FNHEs that they couldnot create before, as both helpers can already be reached with little tono validation. For example, by sending an ICMP error that quotes an ICMPEcho Reply or one that quotes a UDP source port that matches a wildcardsocket.Also note that in the good case (matched socket) the above scheme comesat the cost of an extra route lookup, as the no socket helpers performtheir own lookup before the one performed by ipv4_sk_update_pmtu() /ipv4_sk_redirect(). When the two resolve to different nexthops, it alsoresults in two exceptions being created for the same destination IP. Onein the FNHE cache of the nexthop resolved by the no socket helpers andanother in the FNHE cache of the nexthop used by the socket.
漏洞公开时间：2026-10-23 21:17:31
漏洞创建时间：2026-10-26 15:03:09
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2026-99077
更多参考(点击展开)
无
漏洞分析指导链接：
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:ipv4: udp: Create exceptions before socket matchingCurrently, when ICMP Fragmentation Needed and Redirect Message packetsare locally delivered and quote a UDP packet, a FIB nexthop exception(FNHE) is only created if the kernel can match the UDP packet to anexisting socket.This behavior allows off-path attackers to conduct a side-channel attackon the FNHE cache in order to discover the ephemeral port used by aconnected UDP socket.Commit 6457378fe796 ( ipv4: use siphash instead of Jenkins infnhe_hashfun() ) and commit 67d6d681e15b ( ipv4: make exception cacheless predictible ) tried to mitigate such attacks by making it harderfor attackers to discover hash collisions in the FNHE cache and byrandomizing the number of exceptions a hash bucket can hold,respectively. Unfortunately, both of the mitigations can be bypassed.Instead, mitigate such attacks by always creating a FNHE, even beforetrying to find a matching socket. Do that by calling ipv4_update_pmtu()and ipv4_redirect(), the helpers used when the quoted packet did notoriginate from a socket.This means that guesses (right or wrong) from an off-path attacker willalways result in a FNHE being created or updated in the cache that theattacker can observe.Pass an oif of 0, in a similar fashion to icmp_err(). This is also theoif used by the socket path for sockets that are not bound to a device.Note that this does not allow attackers to create FNHEs that they couldnot create before, as both helpers can already be reached with little tono validation. For example, by sending an ICMP error that quotes an ICMPEcho Reply or one that quotes a UDP source port that matches a wildcardsocket.Also note that in the good case (matched socket) the above scheme comesat the cost of an extra route lookup, as the no socket helpers performtheir own lookup before the one performed by ipv4_sk_update_pmtu() /ipv4_sk_redirect(). When the two resolve to different nexthops, it alsoresults in two exceptions being created for the same destination IP. Onein the FNHE cache of the nexthop resolved by the no socket helpers andanother in the FNHE cache of the nexthop used by the socket.
openEuler评分：
7.4
Vector：CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
受影响版本排查(受影响/不受影响)：
1.master(6.18.40):不受影响
2.openEuler-20.03-LTS-SP4(4.19.90):受影响
3.openEuler-22.03-LTS-SP3(5.10.0):受影响
4.openEuler-22.03-LTS-SP4(5.10.0):受影响
5.openEuler-24.03-LTS(6.6.0):受影响
6.openEuler-24.03-LTS-Next(6.6.0):不受影响
7.openEuler-24.03-LTS-SP1(6.6.0):受影响
8.openEuler-24.03-LTS-SP2(6.6.0):受影响
9.openEuler-24.03-LTS-SP3(6.6.0):受影响
10.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-SP3(5.10.0):否
4.openEuler-22.03-LTS-SP4(5.10.0):否
5.openEuler-24.03-LTS(6.6.0):否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-24.03-LTS-SP1(6.6.0):否
8.openEuler-24.03-LTS-SP2(6.6.0):否
9.openEuler-24.03-LTS-SP3(6.6.0):否
10.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-SP3(5.10.0):不修复-超出修复范围
4.openEuler-22.03-LTS-SP4(5.10.0):不修复-超出修复范围
5.openEuler-24.03-LTS(6.6.0):不修复-超出修复范围
6.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1(6.6.0):暂不修复-漏洞仍在分析中
8.openEuler-24.03-LTS-SP2(6.6.0):不修复-超出修复范围
9.openEuler-24.03-LTS-SP3(6.6.0):暂不修复-漏洞仍在分析中
10.openEuler-24.03-LTS-SP4(6.6.0):暂不修复-漏洞仍在分析中