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

影响性分析说明:

openEuler评分: (评分和向量)

受影响版本排查(受影响/不受影响):
1.master(6.18.18):
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.18):
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.18):
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版本分支受影响，那原因说明只能是受影响对应的原因之一!)：

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下评论 '/report-patch 参考网址 补丁链接1,补丁链接2' 反馈正确信息，便于我们不断优化工具，不胜感激。
如 /report-patch https://security-tracker.debian.org/tracker/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1

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, @GongLei-, @LiuYongQiang0816, @SuperSix173, @Tankll2021, @TrueAI, @allen-shi, @baratta, @caixu-blue, @chen-jun-hw, @chenjiesong, @chenjunxin1992, @chenke2026, @chiqijun, @chriszjh, @duanqiangwen, @fangfeng123, @fanghaiqinghw, @gaojuxin09, @gouhao2022, @guzitao, @hanjunguo, @hanliyang, @hellotcc, @henryze, @hewanhan, @hjx_gitff, @hongbo-lee, @hongwu-wang, @htforge, @hu-chunzhi, @hunan4222, @jackknight, @jerry_lilijun, @jiayi0118, @junlong-zheng, @juntianlinux, @kailiu42, @kaitiandu, @kazero00, @kevinzhu1, @kile2009, @koishimind, @kongzizaixian, @kylin-mayukun, @leoliu-oc, @li-huisong, @linan888, @linyunsheng, @liulongfang, @liyihang0226, @lostway1, @lujialin2, @markyuan4ta21, @mingqian218472, @mingrui-liu, @mufengyan, @pigalsofine, @robinorg, @rock_hw, @sanglipeng, @shu-shengming, @shuaijiakun, @sming56_admin, @stavewu, @stkid, @wangboe2022, @wenzhiwei11, @whoisxxx, @wkfxxx, @woqidaideshi, @wsoydl, @xingmz1, @xukuohai, @yeweihua999, @ygn-ndwd-official, @yonghu_4dc5, @young-sun, @yuehaibing_planb, @yuzenghui1, @zhang-changzhong, @zhangyi089, @zhujianwei001, @zichengqu, @zqiao216 .

/create_pr

branch: OLK-6.6
name: Zizhi Wo
email: wozizhi@huawei.com

/create_pr

branch: OLK-6.6
name: Zizhi Wo
email: wozizhi@huawei.com

已触发 CVE 修复服务，CVE-ID: CVE-2026-52990。
provided by DevStation.

⚠️ CVE 修复任务在获取提交信息步骤（get_commits）失败，CVE-ID: CVE-2026-52990。

原因：[ERROR]Failed to obtain submission information: 未能获取完整的修复提交(fixed)，无法继续流程。

在未能找到完整的引入/修复提交（introduced / fixed commit）之前，系统无法继续后续的分支分析和自动创建 PR 流程。

建议：

1. 确认 CVE ID 是否填写正确；
2. 查看上游社区/内核仓库的安全公告或提交历史，尝试人工定位相关提交；
3. 如该 CVE 为新近分配，可能暂未公开完整修复信息，可联系维护者或安全团队确认。

provided by DevStation.

⚠️ CVE 修复任务在获取提交信息步骤（get_commits）失败，CVE-ID: CVE-2026-52990。

原因：[ERROR]Failed to obtain submission information: 未能获取完整的修复提交(fixed)，无法继续流程。

在未能找到完整的引入/修复提交（introduced / fixed commit）之前，系统无法继续后续的分支分析和自动创建 PR 流程。

建议：

1. 确认 CVE ID 是否填写正确；
2. 查看上游社区/内核仓库的安全公告或提交历史，尝试人工定位相关提交；
3. 如该 CVE 为新近分配，可能暂未公开完整修复信息，可联系维护者或安全团队确认。

provided by DevStation.

/create_pr

branch: OLK-6.6
name: Zizhi Wo
email: wozizhi@huawei.com

已触发 CVE 修复服务，CVE-ID: CVE-2026-52990。
provided by DevStation.

⚠️ CVE 修复任务在获取提交信息步骤（get_commits）失败，CVE-ID: CVE-2026-52990。

原因：[ERROR]Failed to obtain submission information: 未能获取完整的修复提交(fixed)，无法继续流程。

在未能找到完整的引入/修复提交（introduced / fixed commit）之前，系统无法继续后续的分支分析和自动创建 PR 流程。

建议：

1. 确认 CVE ID 是否填写正确；
2. 查看上游社区/内核仓库的安全公告或提交历史，尝试人工定位相关提交；
3. 如该 CVE 为新近分配，可能暂未公开完整修复信息，可联系维护者或安全团队确认。

provided by DevStation.

/create_pr

branch: OLK-6.6
name: Zizhi Wo
email: wozizhi@huawei.com

已触发 CVE 修复服务，CVE-ID: CVE-2026-52990。
provided by DevStation.

已完成 CVE 修复全流程汇总，CVE-ID: CVE-2026-52990。

关联修复提交信息：fsnotify: fix inode reference leak in fsnotify_recalc_mask()

provided by DevStation.

CVE-2026-52990

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

fsnotify: fix inode reference leak in fsnotify_recalc_mask()

fsnotify_recalc_mask() fails to handle the return value of
__fsnotify_recalc_mask(), which may return an inode pointer that needs
to be released via fsnotify_drop_object() when the connector's HAS_IREF
flag transitions from set to cleared.

This manifests as a hung task with the following call trace:

INFO: task umount:1234 blocked for more than 120 seconds.
Call Trace:
__schedule
schedule
fsnotify_sb_delete
generic_shutdown_super
kill_anon_super
cleanup_mnt
task_work_run
do_exit
do_group_exit

The race window that triggers the iref leak:

Thread A (adding mark) Thread B (removing mark)
────────────────────── ────────────────────────
fsnotify_add_mark_locked():
fsnotify_add_mark_list():
spin_lock(conn->lock)
add mark_B(evictable) to list
spin_unlock(conn->lock)
return

/* ---- gap: no lock held ---- */

                                  fsnotify_detach_mark(mark_A):
                                    spin_lock(mark_A->lock)
                                    clear ATTACHED flag on mark_A
                                    spin_unlock(mark_A->lock)
                                    fsnotify_put_mark(mark_A)

fsnotify_recalc_mask():
  spin_lock(conn->lock)
  __fsnotify_recalc_mask():
    /* mark_A skipped: ATTACHED cleared */
    /* only mark_B(evictable) remains */
    want_iref = false
    has_iref = true  /* not yet cleared */
    -> HAS_IREF transitions true -> false
    -> returns inode pointer
  spin_unlock(conn->lock)
  /* BUG: return value discarded!
   * iput() and fsnotify_put_sb_watched_objects()
   * are never called */

Fix this by deferring the transition true -> false of HAS_IREF flag from
fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).

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

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

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

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

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

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

CVE-2026-52990

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

fsnotify: fix inode reference leak in fsnotify_recalc_mask()

fsnotify_recalc_mask() fails to handle the return value of
__fsnotify_recalc_mask(), which may return an inode pointer that needs
to be released via fsnotify_drop_object() when the connector's HAS_IREF
flag transitions from set to cleared.

This manifests as a hung task with the following call trace:

INFO: task umount:1234 blocked for more than 120 seconds.
Call Trace:
__schedule
schedule
fsnotify_sb_delete
generic_shutdown_super
kill_anon_super
cleanup_mnt
task_work_run
do_exit
do_group_exit

The race window that triggers the iref leak:

Thread A (adding mark) Thread B (removing mark)
────────────────────── ────────────────────────
fsnotify_add_mark_locked():
fsnotify_add_mark_list():
spin_lock(conn->lock)
add mark_B(evictable) to list
spin_unlock(conn->lock)
return

/* ---- gap: no lock held ---- */

                                  fsnotify_detach_mark(mark_A):
                                    spin_lock(mark_A->lock)
                                    clear ATTACHED flag on mark_A
                                    spin_unlock(mark_A->lock)
                                    fsnotify_put_mark(mark_A)

fsnotify_recalc_mask():
  spin_lock(conn->lock)
  __fsnotify_recalc_mask():
    /* mark_A skipped: ATTACHED cleared */
    /* only mark_B(evictable) remains */
    want_iref = false
    has_iref = true  /* not yet cleared */
    -> HAS_IREF transitions true -> false
    -> returns inode pointer
  spin_unlock(conn->lock)
  /* BUG: return value discarded!
   * iput() and fsnotify_put_sb_watched_objects()
   * are never called */

Fix this by deferring the transition true -> false of HAS_IREF flag from
fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).

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

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

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

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

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

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

CVE-2026-52990

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

fsnotify: fix inode reference leak in fsnotify_recalc_mask()

fsnotify_recalc_mask() fails to handle the return value of
__fsnotify_recalc_mask(), which may return an inode pointer that needs
to be released via fsnotify_drop_object() when the connector's HAS_IREF
flag transitions from set to cleared.

This manifests as a hung task with the following call trace:

INFO: task umount:1234 blocked for more than 120 seconds.
Call Trace:
__schedule
schedule
fsnotify_sb_delete
generic_shutdown_super
kill_anon_super
cleanup_mnt
task_work_run
do_exit
do_group_exit

The race window that triggers the iref leak:

Thread A (adding mark) Thread B (removing mark)
────────────────────── ────────────────────────
fsnotify_add_mark_locked():
fsnotify_add_mark_list():
spin_lock(conn->lock)
add mark_B(evictable) to list
spin_unlock(conn->lock)
return

/* ---- gap: no lock held ---- */

                                  fsnotify_detach_mark(mark_A):
                                    spin_lock(mark_A->lock)
                                    clear ATTACHED flag on mark_A
                                    spin_unlock(mark_A->lock)
                                    fsnotify_put_mark(mark_A)

fsnotify_recalc_mask():
  spin_lock(conn->lock)
  __fsnotify_recalc_mask():
    /* mark_A skipped: ATTACHED cleared */
    /* only mark_B(evictable) remains */
    want_iref = false
    has_iref = true  /* not yet cleared */
    -> HAS_IREF transitions true -> false
    -> returns inode pointer
  spin_unlock(conn->lock)
  /* BUG: return value discarded!
   * iput() and fsnotify_put_sb_watched_objects()
   * are never called */

Fix this by deferring the transition true -> false of HAS_IREF flag from
fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).

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

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

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

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

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

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

经过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:不修复-超出修复范围