Open
CVE-2026-89665 #18931
zhangxiaoxuAdd on  Sep 15
zhangxiaoxu
Sep 15 Create

一、漏洞信息
漏洞编号:CVE-2026-89665
漏洞归属组件:kernel
漏洞归属的版本:5.10.0
CVSS评分:
BaseScore:8.2 High
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
漏洞简述:
In the Linux kernel, the following vulnerability has been resolved:nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATEThe NFSv2 sattr decoder converts the wire useconds to nanoseconds insvcxdr_decode_sattr(): iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed inunsigned long. On ILP32 that is 32 bits, and an out-of-range usecondsvalue such as 4294968 wraps to tv_nsec == 704. The corruption thereforehappens during decode, before any proc function can inspect the value,and a later range check on tv_nsec would see an in-range result andaccept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply.NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to returnfor a malformed time argument, and the check cannot move to the procfunction the way the v3/v4 nsec range checks do.Guard the raw useconds before the multiplication and reject valuesgreater than 1000000. useconds == 1000000 is kept: it is the Sunconvention for set to the current server time , and the in-tree LinuxNFSv2 client emits it in both the atime and the mtime field for a plaintouch / utimes(file, NULL) (see encode_sattr() andxdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000would turn that common operation into a hard decode failure for bothSETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrapon ILP32, so the Sun convention value passes through safely. Onlygenuinely out-of-range values (> 1000000) are rejected. The atime andmtime guards are therefore symmetric.The decoder only applied the Sun convention in the mtime block, whichclears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If aclient puts 1000000 in the atime field but not in the mtime field, theatime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SETset, so the bogus value reached the filesystem. Apply the convention inthe atime block as well, clearing ATTR_ATIME_SET so the server uses itscurrent time and ignores the value. Only ATTR_ATIME_SET is cleared there.The mtime block keeps its existing behavior, where 1000000 means setboth atime and mtime to now .[ cel: various tweaks, addenda, and clean-ups ]
漏洞公开时间:2026-09-12 04:19:52
漏洞创建时间:2026-09-15 01:40:46
漏洞详情参考链接:
https://nvd.nist.gov/vuln/detail/CVE-2026-89665

更多参考(点击展开)

无

漏洞分析指导链接:
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:nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATEThe NFSv2 sattr decoder converts the wire useconds to nanoseconds insvcxdr_decode_sattr():iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed inunsigned long. On ILP32 that is 32 bits, and an out-of-range usecondsvalue such as 4294968 wraps to tv_nsec == 704. The corruption thereforehappens during decode, before any proc function can inspect the value,and a later range check on tv_nsec would see an in-range result andaccept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply.NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to returnfor a malformed time argument, and the check cannot move to the procfunction the way the v3/v4 nsec range checks do.Guard the raw useconds before the multiplication and reject valuesgreater than 1000000. useconds == 1000000 is kept: it is the Sunconvention for "set to the current server time", and the in-tree LinuxNFSv2 client emits it in both the atime and the mtime field for a plaintouch / utimes(file, NULL) (see encode_sattr() andxdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000would turn that common operation into a hard decode failure for bothSETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrapon ILP32, so the Sun convention value passes through safely. Onlygenuinely out-of-range values (> 1000000) are rejected. The atime andmtime guards are therefore symmetric.The decoder only applied the Sun convention in the mtime block, whichclears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If aclient puts 1000000 in the atime field but not in the mtime field, theatime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SETset, so the bogus value reached the filesystem. Apply the convention inthe atime block as well, clearing ATTR_ATIME_SET so the server uses itscurrent time and ignores the value. Only ATTR_ATIME_SET is cleared there.The mtime block keeps its existing behavior, where 1000000 means "setboth atime and mtime to now".[ cel: various tweaks, addenda, and clean-ups ]The Linux kernel CVE team has assigned CVE-2026-89665 to this issue.
openEuler评分:
8.2
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
受影响版本排查(受影响/不受影响):
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):不修复-超出修复范围

likedislike
devstation-robot
devstation-robot
Sep 15 Comments:

检测到新建 CVE Issue,CVE-ID: CVE-2026-89665。

你可以通过以下两种方式使用 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.

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 15 Modify description of issue
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 15 Assign kongzizaixian as responsible person
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 15 Comments:

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

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 15 Added label: CVE/UNFIXED
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 15 Comments:
参考网址 关联pr 状态 补丁链接
https://www.opencve.io/cve/CVE-2026-89665NoneNonehttps://git.kernel.org/stable/c/5296a2442d12d45d6eea7b4d3ec3ffecc1821cac
https://git.kernel.org/stable/c/1195483965a5f63d2dde18054ec7e50a23b9071c
https://git.kernel.org/stable/c/1db456ffc22e045f49f7b9e62415a26b3f33f200
https://git.kernel.org/stable/c/a937dd1aa2d92291fe0a1860d17e90d8f206cd22
https://git.kernel.org/stable/c/cdc3299f7072777b09c9582a3b8b65bb163ddcf3
https://git.kernel.org/stable/c/26709c8ffe73772eb69e68d553ac71d91228dccc
https://git.kernel.org/stable/c/ad02d095439f89cbd6629420c7e3ba476457b83b
https://git.kernel.org/stable/c/09a79d9ab35a39603c834e8f6333603292f9c816
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2026-89665
https://security-tracker.debian.org/tracker/CVE-2026-89665NoneNonehttps://git.kernel.org/linus/26709c8ffe73772eb69e68d553ac71d91228dccc
http://www.cnnvd.org.cn/web/vulnerability/queryLds.tag?qcvCnnvdid=CVE-2026-89665
https://nvd.nist.gov/vuln/detail/CVE-2026-89665
https://ubuntu.com/security/CVE-2026-89665NoneNonehttps://discourse.ubuntu.com/c/project
https://git.kernel.org/stable/c/1195483965a5f63d2dde18054ec7e50a23b9071c
https://git.kernel.org/linus/26709c8ffe73772eb69e68d553ac71d91228dccc
https://git.kernel.org/stable/c/a937dd1aa2d92291fe0a1860d17e90d8f206cd22
https://git.kernel.org/stable/c/26709c8ffe73772eb69e68d553ac71d91228dccc
https://git.kernel.org/stable/c/ad02d095439f89cbd6629420c7e3ba476457b83b
https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

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

likedislike
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 15 Comments:

@zhangxiaoxv CVE信息从NVD同步失败, 请稍后重试, 或者数据源不存在.

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 15 Assign wkfxxx、zeng_zhaorong、sanglipeng、oekernel、zhangxiaoxv、hanjunguo as responsible person
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 15 Added label: sig/Kernel
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 15 Comments:

Welcome 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, @chiqijun, @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, @jackknight, @jerry_lilijun, @jiayi0118, @junlong-zheng, @juntianlinux, @kailiu42, @kaitiandu, @kazero00, @kevinzhu1, @kile2009, @klmengkd, @koishimind, @kongzizaixian, @kunlun_spurs, @kylin-mayukun, @leoliu-oc, @li-huisong, @linan888, @linyunsheng, @liulongfang, @liyihang0226, @lostway1, @lujialin2, @mao-hongbo, @markyuan4ta21, @mawupeng, @mingqian218472, @mingrui-liu, @mufengyan, @nebulamatrix_rdma, @peterpangogogo, @pigalsofine, @robinorg, @rock_hw, @sanglipeng, @shu-shengming, @shuaijiakun, @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, @zhangyi089, @zhujianwei001, @zichengqu, @zouyipeng, @zqiao216 .

likedislike
hulk-ci-botCollaborators
Sep 15 Comments:

CVE-2026-89665

影响性分析说明:
In the Linux kernel, the following vulnerability has been resolved:

nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE

The NFSv2 sattr decoder converts the wire useconds to nanoseconds in
svcxdr_decode_sattr():

iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;

tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in
unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds
value such as 4294968 wraps to tv_nsec == 704. The corruption therefore
happens during decode, before any proc function can inspect the value,
and a later range check on tv_nsec would see an in-range result and
accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply.
NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return
for a malformed time argument, and the check cannot move to the proc
function the way the v3/v4 nsec range checks do.

Guard the raw useconds before the multiplication and reject values
greater than 1000000. useconds == 1000000 is kept: it is the Sun
convention for "set to the current server time", and the in-tree Linux
NFSv2 client emits it in both the atime and the mtime field for a plain
touch / utimes(file, NULL) (see encode_sattr() and
xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000
would turn that common operation into a hard decode failure for both
SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap
on ILP32, so the Sun convention value passes through safely. Only
genuinely out-of-range values (> 1000000) are rejected. The atime and
mtime guards are therefore symmetric.

The decoder only applied the Sun convention in the mtime block, which
clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a
client puts 1000000 in the atime field but not in the mtime field, the
atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET
set, so the bogus value reached the filesystem. Apply the convention in
the atime block as well, clearing ATTR_ATIME_SET so the server uses its
current time and ignores the value. Only ATTR_ATIME_SET is cleared there.
The mtime block keeps its existing behavior, where 1000000 means "set
both atime and mtime to now".

[ cel: various tweaks, addenda, and clean-ups ]

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

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

受影响版本排查(受影响/不受影响):
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:暂不修复-漏洞仍在分析中

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 15 Modify description of issue
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 15 Removed responsible person zeng_zhaorong、kongzizaixian、sanglipeng、oekernel、zhangxiaoxv、hanjunguo
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 15 Comments:

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

状态 分析项目 内容
已分析 1.影响性分析说明 In the Linux kernel, the following vulnerability has been resolved:nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATEThe NFSv2 sattr decoder converts the wire useconds to nanoseconds insvcxdr_decode_sattr():iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed inunsigned long. On ILP32 that is 32 bits, and an out-of-range usecondsvalue such as 4294968 wraps to tv_nsec == 704. The corruption thereforehappens during decode, before any proc function can inspect the value,and a later range check on tv_nsec would see an in-range result andaccept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply.NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to returnfor a malformed time argument, and the check cannot move to the procfunction the way the v3/v4 nsec range checks do.Guard the raw useconds before the multiplication and reject valuesgreater than 1000000. useconds == 1000000 is kept: it is the Sunconvention for "set to the current server time", and the in-tree LinuxNFSv2 client emits it in both the atime and the mtime field for a plaintouch / utimes(file, NULL) (see encode_sattr() andxdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000would turn that common operation into a hard decode failure for bothSETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrapon ILP32, so the Sun convention value passes through safely. Onlygenuinely out-of-range values (> 1000000) are rejected. The atime andmtime guards are therefore symmetric.The decoder only applied the Sun convention in the mtime block, whichclears ATTR_ATIME_SET
已分析 2.openEulerScore 8.2
已分析 3.openEulerVector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
已分析 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:不修复-超出修复范围

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

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 15 changed custom state from 待办的 to 进行中
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 16 Modify description of issue
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 17 Modify description of issue
lujialin2
lujialin2Collaborators
Sep 30 Comments:

/create_pr

branch: OLK-6.6 OLK-5.10
name: Lu Jialin
email: lujialin4@huawei.com
backport-engine: opencode

likedislike
devstation-robot
devstation-robot
Sep 30 Comments:

CVE: CVE-2026-89665 · Workflow: 33ccc1405ae04a029fbd70098a980073 · Attempt: 1
状态:已结束

分支 状态 PR / 错误 结果说明
OLK-6.6 succeeded https://gitcode.com/openeuler/kernel/merge_requests/29121 [source: cve_manager: empty, linux_cna: selected]
OLK-5.10 failed source_metadata unavailable (cve_manager: empty; linux_cna: request_error) [source_metadata: cve_manager: empty, linux_cna: request_error]

显式重试:/retry 33ccc1405ae04a029fbd70098a980073(将重跑全部分支,重新验证来源并生成新的 Attempt)。

likedislike
devstation-robotdevstation-robot
Sep 30 Associated pull request
Oopeneuler-infra-botCollaborators
29 days ago Associated pull request
Oopeneuler-infra-botCollaborators
17 days ago Associated pull request
openeuler-ci-botopeneuler-ci-botCollaborators
7 days ago changed custom priority from 无优先级 to 主要