CVE-2026-89762-kernel-AtomGit

已开启

CVE-2026-89762 #18955

zhangxiaoxu创建于 26 天前

26 天前创建

一、漏洞信息
漏洞编号：CVE-2026-89762
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.12.33,6.18.18,6.18.40,6.4.0,6.6.0
CVSS评分：
BaseScore：7.8 High
Vector：CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
漏洞简述：
In the Linux kernel, the following vulnerability has been resolved:apparmor: fix cred UAF caused by begin_current_label_crit_section()AppArmor s begin_current_label_crit_section() is a scary function calledfrom lots of LSM hooks (in particular VFS/socket-related ones) that checksif the label referenced by the current creds is marked FLAG_STALE, and ifso, attempts to use aa_replace_current_label() to replace the creds with anupdated version that uses a new label.The first problem with this is that it would directly lead to UAF ofstruct cred if anything in the kernel takes a pointer to the currentcreds and accesses these past a security hook invocation that replacescreds, like so:const struct cred *cred = current_cred();alloc_file_pseudo(...);uid_t uid = cred->euid;I don t know if anything in the kernel actually does this, but I think itis very surprising that this pattern could lead to UAF.The second problem is that things go wrong when aa_replace_current_label()runs with overridden credentials. aa_replace_current_label() bails out ifcurrent_cred() != current_real_cred() (mirroring the check inproc_pid_attr_write()), but this check can t actually reliably detectoverridden credentials because the overridden creds can be the same as theobjective creds.So in approximately the following scenario, things go wrong:1. task begins with (as both objective and subjective creds), with refcount=22. task grabs an extra reference on for overriding3. task calls override_creds(), which returns a pointer to the old subjective creds ()4. task enters AppArmor LSM hook5. AppArmor checks that objective/subjective creds are equal6. AppArmor replaces both cred pointers with and drops 2 refs on 7. task leaves AppArmor LSM hook8. task calls revert_creds()9. now task->cred is while task->real_cred is , but the task_struct logically holds two references to 10. another task drops the extra reference on that was used for overriding, refcount drops to 011. now task->real_cred points to freed credsAt this point, any access to current_cred() will be UAF.I have a test case where I run aa-disable on a profile while a processusing that profile is blocked on splice() from a FUSE passthrough file intoa full pipe; after the profile update, the pipe becomes empty, splice()resumes, the credentials go out of sync, and a subsequent getuid() syscallresults in a KASAN UAF splat.To fix this, instead of directly replacing creds, do it via task_work thatwill run at the end of the current syscall. (The point in time at which thecred replacement happens should have no correctness impact; it is just aperformance optimization to avoid unnecessarily touching the refcount ofthe new label.)Note that AppArmor still performs direct cred replacements in thesb_pivotroot LSM hook after this change, and that direct cred replacementscan still happen in VFS ->write() callbacks via proc_pid_attr_write().There are two options for what to do with aa_dup_task_ctx(): Eitherexplicitly reset new->label_replacement_pending after the entireaa_task_ctx has been copied, or switch to manually copying members over.I am switching to manually copying members over because that should makebugs more obvious.
漏洞公开时间：2026-09-12 04:20:07
漏洞创建时间：2026-09-15 03:00:13
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2026-89762

更多参考(点击展开)

参考来源	参考链接	来源链接
	https://lore.kernel.org/linux-cve-announce/2026091109-CVE-2026-89762-4aa8@gregkh/T/#u
	https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2
	https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540
	https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47
	https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f

漏洞分析指导链接：
https://atomgit.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
七彩瞬析开源风险感知平台
漏洞补丁信息：

详情(点击展开)

影响的包	修复补丁	来源
gregkh/linux	https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f	ljqc
gregkh/linux	https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540	ljqc
gregkh/linux	https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2	ljqc
gregkh/linux	https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47	ljqc
	https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2	cvelistv5
	https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540	cvelistv5
	https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47	cvelistv5
	https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f	cvelistv5

二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:apparmor: fix cred UAF caused by begin_current_label_crit_section()AppArmor's begin_current_label_crit_section() is a scary function calledfrom lots of LSM hooks (in particular VFS/socket-related ones) that checksif the label referenced by the current creds is marked FLAG_STALE, and ifso, attempts to use aa_replace_current_label() to replace the creds with anupdated version that uses a new label.The first problem with this is that it would directly lead to UAF ofstruct cred if anything in the kernel takes a pointer to the currentcreds and accesses these past a security hook invocation that replacescreds, like so:const struct cred *cred = current_cred();alloc_file_pseudo(...);uid_t uid = cred->euid;I don't know if anything in the kernel actually does this, but I think itis very surprising that this pattern could lead to UAF.The second problem is that things go wrong when aa_replace_current_label()runs with overridden credentials. aa_replace_current_label() bails out ifcurrent_cred() != current_real_cred() (mirroring the check inproc_pid_attr_write()), but this check can't actually reliably detectoverridden credentials because the overridden creds can be the same as theobjective creds.So in approximately the following scenario, things go wrong:1. task begins with <creds A> (as both objective and subjective creds), with refcount=22. task grabs an extra reference on <creds A> for overriding3. task calls override_creds(<creds A>), which returns a pointer to the old subjective creds (<creds A>)4. task enters AppArmor LSM hook5. AppArmor checks that objective/subjective creds are equal6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on <creds A>7. task leaves AppArmor LSM hook8. task calls revert_creds(<creds A>)9. now task->cred is <creds A> while task->real_cred is <creds B>, but the task_struct logically holds two references to <creds B>10. another task drops the extra reference on <creds A> that was used for overriding, refcount drops to 011. now task->real_cred points to freed credsAt this point, any access to current_cred() will be UAF.I have a test case where I run aa-disable on a profile while a processusing that profile is blocked on splice() from a FUSE passthrough file intoa full pipe; after the profile update, the pipe becomes empty, splice()resumes, the credentials go out of sync, and a subsequent getuid() syscallresults in a KASAN UAF splat.To fix this, instead of directly replacing creds, do it via task_work thatwill run at the end of the current syscall. (The point in time at which thecred replacement happens should have no correctness impact; it is just aperformance optimization to avoid unnecessarily touching the refcount ofthe new label.)Note that AppArmor still performs direct cred replacements in thesb_pivotroot LSM hook after this change, and that direct cred replacementscan still happen in VFS ->write() callbacks via proc_pid_attr_write().There are two options for what to do with aa_dup_task_ctx(): Eitherexplicitly reset new->label_replacement_pending after the entireaa_task_ctx has been copied, or switch to manually copying members over.I am switching to manually copying members over because that should makebugs more obvious.The Linux kernel CVE team has assigned CVE-2026-89762 to this issue.
openEuler评分：
7.8
Vector：CVSS:3.1/AV:L/AC:L/PR:L/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):不修复-超出修复范围

devstation-robot

26 天前评论：

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

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

分支影响分析
- 在本 Issue 下评论：/analysis_branches
- 系统将自动分析各个分支是否受影响，并在本 Issue 下给出表格形式的分析结果；
在指定分支上创建 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.

分支状态	原因说明	使用场景
受影响	正常修复	受影响且需要修复（包含升级版本修复）的漏洞；受影响且已经修复的漏洞（历史修复PR也需要关联issue）；若因特殊原因无法修复，应修改原因说明为【不修复-特殊原因】，并在安委会备案相关情况。
受影响	暂不修复-漏洞仍在分析中	已关注到相关漏洞，正在处理，未明确漏洞影响和修复方案。
受影响	暂不修复-暂无解决方案或补丁	当前没有可用的修复或补救措施。【影响性分析】中应包含有关为什么没有修复或补救措施的详细说明、上游相关PR等。
受影响	不修复-超出修复范围	没有漏洞的修复计划。当版本停维、软件包宣布生命周期终止或弃用使用。
受影响	不修复-特殊原因导致不再修复	如存在其他特殊情况不修复相关漏洞，或评估后无法升级修复，应在openEuler社区安全委员会例会进行说明备案。【影响性分析】中应包含不发布修复的详细说明、特殊情况还应有安委会会议纪要。
不受影响	不受影响-组件不存在	软件不受影响，因为易受攻击的组件不在产品中。
不受影响	不受影响-已有内置的内联控制或缓解措施	内置的内联控制或缓解措施可防止攻击者利用漏洞
不受影响	不受影响-漏洞代码不能被攻击者触发	易受攻击的组件存在，并且该组件包含易受攻击的代码。但是，易受攻击的代码的使用方式使得攻击者无法进行任何预期的攻击。
不受影响	不受影响-漏洞代码不在执行路径	易受影响的代码在执行过程中不可访问，包括产品的非预期状态。产品不使用也不执行的组件。
不受影响	不受影响-漏洞代码不存在	产品不受影响，因为漏洞背后的代码在产品中不存在。与component_not_present不同的是，有问题的组件存在，但由于某种原因（例如安全的编译器选项）使漏洞的特定代码不存在于组件中。

参考网址	关联pr	状态	补丁链接
https://www.opencve.io/cve/CVE-2026-89762	None	None	https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47 https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2 https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540 https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2026-89762
https://security-tracker.debian.org/tracker/CVE-2026-89762	None	None	https://git.kernel.org/linus/3f4ae5fab613dca01d6a2a8210dd832e009fcf47
http://www.cnnvd.org.cn/web/vulnerability/queryLds.tag?qcvCnnvdid=CVE-2026-89762
https://nvd.nist.gov/vuln/detail/CVE-2026-89762
https://ubuntu.com/security/CVE-2026-89762	None	None	https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47 https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540 https://git.kernel.org/linus/c75afcd153f6147d3b094f45a1d87e5df7f4f053 https://discourse.ubuntu.com/c/project https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2 https://git.kernel.org/linus/3f4ae5fab613dca01d6a2a8210dd832e009fcf47

状态	分析项目	内容
已分析	1.影响性分析说明	In the Linux kernel, the following vulnerability has been resolved:apparmor: fix cred UAF caused by begin_current_label_crit_section()AppArmor's begin_current_label_crit_section() is a scary function calledfrom lots of LSM hooks (in particular VFS/socket-related ones) that checksif the label referenced by the current creds is marked FLAG_STALE, and ifso, attempts to use aa_replace_current_label() to replace the creds with anupdated version that uses a new label.The first problem with this is that it would directly lead to UAF of`struct cred` if anything in the kernel takes a pointer to the currentcreds and accesses these past a security hook invocation that replacescreds, like so:`const struct cred *cred = current_cred();alloc_file_pseudo(...);uid_t uid = cred->euid;`I don't know if anything in the kernel actually does this, but I think itis very surprising that this pattern could lead to UAF.The second problem is that things go wrong when aa_replace_current_label()runs with overridden credentials. aa_replace_current_label() bails out if`current_cred() != current_real_cred()` (mirroring the check inproc_pid_attr_write()), but this check can't actually reliably detectoverridden credentials because the overridden creds can be the same as theobjective creds.So in approximately the following scenario, things go wrong:1. task begins with <creds A> (as both objective and subjective creds), with refcount=22. task grabs an extra reference on <creds A> for overriding3. task calls override_creds(<creds A>), which returns a pointer to the old subjective creds (<creds A>)4. task enters AppArmor LSM hook5. AppArmor checks that objective/subjective creds are equal6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on <creds A>7. task leaves AppArmor LSM hook8. task calls revert_creds(<creds A>)9. now task->cred is <creds A> while task->real_cred is <creds B>, but the task_struct logically holds two references to <creds B>10. another task drops the extra reference on <creds A> that was used for overriding, refcount drops to 011. now task->real_cred points to freed credsAt this point, any access to current_cred() will be UAF.I have a test case where I run aa-disable on a profile while a processusing that profile is blocked on splice() from a FUSE passthrough file intoa full pipe; after the profile update, the pipe becomes empty, splice()resumes, the credentials go out of sync, and a subsequent getuid() syscallresults in a KASAN UAF splat.To fix this, instead of directly replacing creds, do it via task_work thatwill run at the end of the current syscall. (The point in time at which thecred replacement happens should have no correctness impact; it is just aperformance optimization to avoid unnecessarily touching the refcount ofthe new label.)Note that AppArmor still performs direct cred replacements in thesb_pivotroot LSM hook after this change, and that direct cred replacementscan still happen in VFS ->write() callbacks via proc_pid_attr_write().There are two options for what to do with aa_dup_task_ctx(): Eitherexplicitly reset new->label_replacement_pending after the entireaa_task_ctx has been copied, or switch to manually copying members over.I am switching to manually copying members over because that should makebugs more obvious.The Linux kernel CVE team has assigned CVE-2026-89762 to this issue.
已分析	2.openEulerScore	7.8
已分析	3.openEulerVector	AV:L/AC:L/PR:L/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:不修复-超出修复范围

分支	状态	PR / 错误
OLK-6.6	succeeded	https://gitcode.com/openeuler/kernel/merge_requests/28427 [source: cve_manager: selected]
OLK-5.10	succeeded	https://gitcode.com/openeuler/kernel/merge_requests/28429 [source: cve_manager: selected]

Welcome To openEuler Community

Bot Usage Manual

Contact Guide