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

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

1. 分支影响分析

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

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

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

/create_pr

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

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

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

provided by DevStation.

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

影响性分析说明:

openEuler评分: (评分和向量)

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

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

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

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

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

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

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 .

CVE-2026-89544

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

SUNRPC: fix gssx_dec_option_array error path bugs

Four coupled defects in the gssx XDR option-array decoder make the
error paths unsafe: a NULL deref in the caller, a refcount leak on
the decoded group_info, and a latent use-after-free that the leak
fix would otherwise expose.

gssx_dec_option_array() sets oa->count = 1 before allocating
oa->data. If that allocation fails, -ENOMEM is returned with
oa->count == 1 and oa->data == NULL. All other error paths jump
to free_oa: which frees oa->data and NULLs it but also leaves
oa->count == 1. The caller trusts the count:

gssp_accept_sec_context_upcall()
  gssx_dec_accept_sec_context()
    gssx_dec_option_array()        /* fails, count=1 data=NULL */
  data = res.options.data[0].value /* NULL deref */

Independently, free_creds: releases the partially decoded svc_cred
with a bare kfree(creds). gssx_dec_linux_creds() installs a
groups_alloc() result into creds->cr_group_info; that object is
kvmalloc-backed and refcounted, and only put_group_info() reaches
kvfree(). A plain kfree(creds) drops the wrapper and leaks the
group_info allocation.

The natural fix for the leak is to call free_svc_cred(creds) before
kfree(creds), but free_svc_cred() invokes put_group_info() on
creds->cr_group_info unconditionally when non-NULL. The existing
out_free_groups: path in gssx_dec_linux_creds() already called
groups_free() on that pointer without clearing it, so once
free_svc_cred() is wired in, the subsequent put_group_info() would
touch freed memory.

Fix all four together:

• Move the oa->count = 1 assignment below the oa->data allocation
  so it is never set when oa->data is NULL.
• Reset oa->count to 0 at free_oa: so count and data stay
  coherent and the caller sees an empty option array.
• Call free_svc_cred(creds) before kfree(creds) at free_creds:
  so the refcounted cr_group_info is released. free_svc_cred()
  either NULL-guards each field explicitly (cr_group_info has
  an if() check) or delegates to a helper that is NULL-safe
  itself (kfree for the string fields, gss_mech_put() which
  guards with if(gm) at gss_mech_switch.c:342), so it is safe
  to call on a partially decoded svc_cred where only
  cr_uid/cr_gid/cr_group_info have been written and everything
  else is zero from kzalloc.
• In gssx_dec_linux_creds()'s out_free_groups: path, release
  cr_group_info with put_group_info() rather than groups_free()
  so the teardown matches free_svc_cred()'s refcount-aware path,
  and clear the pointer so a later free_svc_cred() on the same
  creds does not release it a second time.

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

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

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

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

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

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

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

CVE-2026-89544

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

SUNRPC: fix gssx_dec_option_array error path bugs

Four coupled defects in the gssx XDR option-array decoder make the
error paths unsafe: a NULL deref in the caller, a refcount leak on
the decoded group_info, and a latent use-after-free that the leak
fix would otherwise expose.

gssx_dec_option_array() sets oa->count = 1 before allocating
oa->data. If that allocation fails, -ENOMEM is returned with
oa->count == 1 and oa->data == NULL. All other error paths jump
to free_oa: which frees oa->data and NULLs it but also leaves
oa->count == 1. The caller trusts the count:

gssp_accept_sec_context_upcall()
  gssx_dec_accept_sec_context()
    gssx_dec_option_array()        /* fails, count=1 data=NULL */
  data = res.options.data[0].value /* NULL deref */

Independently, free_creds: releases the partially decoded svc_cred
with a bare kfree(creds). gssx_dec_linux_creds() installs a
groups_alloc() result into creds->cr_group_info; that object is
kvmalloc-backed and refcounted, and only put_group_info() reaches
kvfree(). A plain kfree(creds) drops the wrapper and leaks the
group_info allocation.

The natural fix for the leak is to call free_svc_cred(creds) before
kfree(creds), but free_svc_cred() invokes put_group_info() on
creds->cr_group_info unconditionally when non-NULL. The existing
out_free_groups: path in gssx_dec_linux_creds() already called
groups_free() on that pointer without clearing it, so once
free_svc_cred() is wired in, the subsequent put_group_info() would
touch freed memory.

Fix all four together:

• Move the oa->count = 1 assignment below the oa->data allocation
  so it is never set when oa->data is NULL.
• Reset oa->count to 0 at free_oa: so count and data stay
  coherent and the caller sees an empty option array.
• Call free_svc_cred(creds) before kfree(creds) at free_creds:
  so the refcounted cr_group_info is released. free_svc_cred()
  either NULL-guards each field explicitly (cr_group_info has
  an if() check) or delegates to a helper that is NULL-safe
  itself (kfree for the string fields, gss_mech_put() which
  guards with if(gm) at gss_mech_switch.c:342), so it is safe
  to call on a partially decoded svc_cred where only
  cr_uid/cr_gid/cr_group_info have been written and everything
  else is zero from kzalloc.
• In gssx_dec_linux_creds()'s out_free_groups: path, release
  cr_group_info with put_group_info() rather than groups_free()
  so the teardown matches free_svc_cred()'s refcount-aware path,
  and clear the pointer so a later free_svc_cred() on the same
  creds does not release it a second time.

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

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

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

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

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

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

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

CVE-2026-89544

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

SUNRPC: fix gssx_dec_option_array error path bugs

Four coupled defects in the gssx XDR option-array decoder make the
error paths unsafe: a NULL deref in the caller, a refcount leak on
the decoded group_info, and a latent use-after-free that the leak
fix would otherwise expose.

gssx_dec_option_array() sets oa->count = 1 before allocating
oa->data. If that allocation fails, -ENOMEM is returned with
oa->count == 1 and oa->data == NULL. All other error paths jump
to free_oa: which frees oa->data and NULLs it but also leaves
oa->count == 1. The caller trusts the count:

gssp_accept_sec_context_upcall()
  gssx_dec_accept_sec_context()
    gssx_dec_option_array()        /* fails, count=1 data=NULL */
  data = res.options.data[0].value /* NULL deref */

Independently, free_creds: releases the partially decoded svc_cred
with a bare kfree(creds). gssx_dec_linux_creds() installs a
groups_alloc() result into creds->cr_group_info; that object is
kvmalloc-backed and refcounted, and only put_group_info() reaches
kvfree(). A plain kfree(creds) drops the wrapper and leaks the
group_info allocation.

The natural fix for the leak is to call free_svc_cred(creds) before
kfree(creds), but free_svc_cred() invokes put_group_info() on
creds->cr_group_info unconditionally when non-NULL. The existing
out_free_groups: path in gssx_dec_linux_creds() already called
groups_free() on that pointer without clearing it, so once
free_svc_cred() is wired in, the subsequent put_group_info() would
touch freed memory.

Fix all four together:

• Move the oa->count = 1 assignment below the oa->data allocation
  so it is never set when oa->data is NULL.
• Reset oa->count to 0 at free_oa: so count and data stay
  coherent and the caller sees an empty option array.
• Call free_svc_cred(creds) before kfree(creds) at free_creds:
  so the refcounted cr_group_info is released. free_svc_cred()
  either NULL-guards each field explicitly (cr_group_info has
  an if() check) or delegates to a helper that is NULL-safe
  itself (kfree for the string fields, gss_mech_put() which
  guards with if(gm) at gss_mech_switch.c:342), so it is safe
  to call on a partially decoded svc_cred where only
  cr_uid/cr_gid/cr_group_info have been written and everything
  else is zero from kzalloc.
• In gssx_dec_linux_creds()'s out_free_groups: path, release
  cr_group_info with put_group_info() rather than groups_free()
  so the teardown matches free_svc_cred()'s refcount-aware path,
  and clear the pointer so a later free_svc_cred() on the same
  creds does not release it a second time.

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

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

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

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

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

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

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