一、漏洞信息
漏洞编号：CVE-2026-52991
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.12.33,6.18.18,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:sched/psi: fix race between file release and pressure writeA potential race condition exists between pressure write and cgroup filerelease regarding the priv member of struct kernfs_open_file, whichtriggers the uaf reported in [1].Consider the following scenario involving execution on two separate CPUs: CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->privThe cgroup_rmdir() is protected by the cgroup_mutex, it also safeguardsthe memory deallocation of of->priv performed within cgroup_file_release().However, the operations involving of->priv executed within pressure_write()are not entirely covered by the protection of cgroup_mutex. Consequently,if the code in pressure_write(), specifically the section handling thectx variable executes after cgroup_file_release() has completed, a uafvulnerability involving of->priv is triggered.Therefore, the issue can be resolved by extending the scope of thecgroup_mutex lock within pressure_write() to encompass all code pathsinvolving of->priv, thereby properly synchronizing the race conditionoccurring between cgroup_file_release() and pressure_write().And, if an live kn lock can be successfully acquired while executingthe pressure write operation, it indicates that the cgroup deletionprocess has not yet reached its final stage; consequently, the privpointer within open_file cannot be NULL. Therefore, the operation toretrieve the ctx value must be moved to a point after the live knlock has been successfully acquired.In another situation, specifically after entering cgroup_kn_lock_live()but before acquiring cgroup_mutex, there exists a different class ofrace condition:CPU0: write memory.pressure CPU1: write cgroup.pressure=0=========================== =============================kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex cgroup_pressure_write() cgroup_kn_lock_live(cgroup.pressure) cgroup_file_show(memory.pressure, false) kernfs_show(false) kernfs_drain_open_files() cgroup_file_release(of) kfree(ctx) of->priv = NULL cgroup_kn_unlock() ... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereferenceConsequently, there is a possibility that of->priv is NULL, the pressurewrite needs to check for this.Now that the scope of the cgroup_mutex has been expanded, the originalexplicit cgroup_get/put operations are no longer necessary, this isbecause acquiring/releasing the live kn lock inherently executes acgroup get/put operation.[1]BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43---truncated---
漏洞公开时间：2026-06-25 01:17:09
漏洞创建时间：2026-06-25 04:07:25
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2026-52991

漏洞分析指导链接：
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:sched/psi: fix race between file release and pressure writeA potential race condition exists between pressure write and cgroup filerelease regarding the priv member of struct kernfs_open_file, whichtriggers the uaf reported in [1].Consider the following scenario involving execution on two separate CPUs: CPU0CPU1 ========vfs_rmdir()kernfs_iop_rmdir()cgroup_rmdir()cgroup_kn_lock_live()cgroup_destroy_locked()cgroup_addrm_files()cgroup_rm_file()kernfs_remove_by_name()kernfs_remove_by_name_ns() vfs_write()__kernfs_remove() new_sync_write()kernfs_drain() kernfs_fop_write_iter()kernfs_drain_open_files() cgroup_file_write()kernfs_release_file() pressure_write()cgroup_file_release() ctx = of->priv;kfree(ctx); of->priv = NULL;cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->privThe cgroup_rmdir() is protected by the cgroup_mutex, it also safeguardsthe memory deallocation of of->priv performed within cgroup_file_release().However, the operations involving of->priv executed within pressure_write()are not entirely covered by the protection of cgroup_mutex. Consequently,if the code in pressure_write(), specifically the section handling thectx variable executes after cgroup_file_release() has completed, a uafvulnerability involving of->priv is triggered.Therefore, the issue can be resolved by extending the scope of thecgroup_mutex lock within pressure_write() to encompass all code pathsinvolving of->priv, thereby properly synchronizing the race conditionoccurring between cgroup_file_release() and pressure_write().And, if an live kn lock can be successfully acquired while executingthe pressure write operation, it indicates that the cgroup deletionprocess has not yet reached its final stage; consequently, the privpointer within open_file cannot be NULL. Therefore, the operation toretrieve the ctx value must be moved to a point after the live knlock has been successfully acquired.In another situation, specifically after entering cgroup_kn_lock_live()but before acquiring cgroup_mutex, there exists a different class ofrace condition:CPU0: write memory.pressure CPU1: write cgroup.pressure=0=========================== =============================kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex cgroup_pressure_write() cgroup_kn_lock_live(cgroup.pressure) cgroup_file_show(memory.pressure, false) kernfs_show(false) kernfs_drain_open_files() cgroup_file_release(of) kfree(ctx) of->priv = NULL cgroup_kn_unlock() ... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereferenceConsequently, there is a possibility that of->priv is NULL, the pressurewrite needs to check for this.Now that the scope of the cgroup_mutex has been expanded, the originalexplicit cgroup_get/put operations are no longer necessary, this isbecause acquiring/releasing the live kn lock inherently executes acgroup get/put operation.[1]BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43---truncated---
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):不修复-超出修复范围