代码拉取完成，页面将自动刷新
一、漏洞信息
漏洞编号：CVE-2024-50144
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0
CVSS V3.0分值：
BaseScore：5.5 Medium
Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
漏洞简述：
In the Linux kernel, the following vulnerability has been resolved:drm/xe: fix unbalanced rpm put() with fence_fini()Currently we can call fence_fini() twice if something goes wrong whensending the GuC CT for the tlb request, since we signal the fence andreturn an error, leading to the caller also calling fini() on the errorpath in the case of stack version of the flow, which leads to an extrarpm put() which might later cause device to enter suspend when itshouldn t. It looks like we can just drop the fini() call since thefence signaller side will already call this for us.There are known mysterious splats with device going to sleep even withan rpm ref, and this could be one candidate.v2 (Matt B): - Prefer warning if we detect double fini()(cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)
漏洞公开时间：2024-11-07 18:15:06
漏洞创建时间：2024-11-07 18:30:34
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2024-50144
漏洞分析指导链接：
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
openBrain开源漏洞感知系统
漏洞补丁信息：
| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源 |
|---|---|---|---|---|
| https://git.kernel.org/stable/c/03a86c24aea0920a1ca20a0d7771d5e176db538d | nvd | |||
| https://git.kernel.org/stable/c/046bd018c0123b1a49c22abed5f9ea31d1454c78 | nvd |
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:drm/xe: fix unbalanced rpm put() with fence_fini()Currently we can call fence_fini() twice if something goes wrong whensending the GuC CT for the tlb request, since we signal the fence andreturn an error, leading to the caller also calling fini() on the errorpath in the case of stack version of the flow, which leads to an extrarpm put() which might later cause device to enter suspend when itshouldn t. It looks like we can just drop the fini() call since thefence signaller side will already call this for us.There are known mysterious splats with device going to sleep even withan rpm ref, and this could be one candidate.v2 (Matt B): - Prefer warning if we detect double fini()(cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)
openEuler评分：
5.5
Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
受影响版本排查(受影响/不受影响)：
1.openEuler-20.03-LTS-SP4(4.19.90):不受影响
2.openEuler-22.03-LTS-SP1(5.10.0):不受影响
3.openEuler-22.03-LTS-SP3(5.10.0):不受影响
4.openEuler-22.03-LTS-SP4(5.10.0):不受影响
5.master(6.6.0):不受影响
6.openEuler-24.03-LTS(6.6.0):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响
8.openEuler-24.03-LTS-SP1(6.6.0):不受影响
修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP1(5.10.0):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.master(6.6.0):否
5.openEuler-24.03-LTS(6.6.0):否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-22.03-LTS-SP4(5.10.0):否
8.openEuler-24.03-LTS-SP1(6.6.0):否
原因说明：
1.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在
2.openEuler-22.03-LTS-SP1(5.10.0):不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP3(5.10.0):不受影响-漏洞代码不存在
4.openEuler-22.03-LTS-SP4(5.10.0):不受影响-漏洞代码不存在
5.master(6.6.0):不受影响-漏洞代码不存在
6.openEuler-24.03-LTS(6.6.0):不受影响-漏洞代码不存在
7.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不存在
8.openEuler-24.03-LTS-SP1(6.6.0):不受影响-漏洞代码不存在
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
hulk-robot
9个月前
CVE-2024-50144
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: fix unbalanced rpm put() with fence_fini()
Currently we can call fence_fini() twice if something goes wrong when
sending the GuC CT for the tlb request, since we signal the fence and
return an error, leading to the caller also calling fini() on the error
path in the case of stack version of the flow, which leads to an extra
rpm put() which might later cause device to enter suspend when it
shouldn't. It looks like we can just drop the fini() call since the
fence signaller side will already call this for us.
There are known mysterious splats with device going to sleep even with
an rpm ref, and this could be one candidate.
v2 (Matt B):
(cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)
The Linux kernel CVE team has assigned CVE-2024-50144 to this issue.
openEuler评分:(评分和向量)
3.9
AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:不受影响
3.openEuler-22.03-LTS-SP3:不受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:不受影响
7.openEuler-24.03-LTS-Next:不受影响
修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否
郭梦琪
7个月前
CVE-2024-50144
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: fix unbalanced rpm put() with fence_fini()
Currently we can call fence_fini() twice if something goes wrong when
sending the GuC CT for the tlb request, since we signal the fence and
return an error, leading to the caller also calling fini() on the error
path in the case of stack version of the flow, which leads to an extra
rpm put() which might later cause device to enter suspend when it
shouldn't. It looks like we can just drop the fini() call since the
fence signaller side will already call this for us.
There are known mysterious splats with device going to sleep even with
an rpm ref, and this could be one candidate.
v2 (Matt B):
(cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)
openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:不受影响
3.openEuler-22.03-LTS-SP3:不受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.master(6.6.0):不受影响
6.openEuler-24.03-LTS:不受影响
7.openEuler-24.03-LTS-Next:不受影响
8.openEuler-24.03-LTS-SP1:不受影响
原因说明:
1.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
2.openEuler-22.03-LTS-SP1:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP3:不受影响-漏洞代码不存在
4.openEuler-22.03-LTS-SP4:不受影响-漏洞代码不存在
5.master(6.6.0):不受影响-漏洞代码不存在
6.openEuler-24.03-LTS:不受影响-漏洞代码不存在
7.openEuler-24.03-LTS-Next:不受影响-漏洞代码不存在
8.openEuler-24.03-LTS-SP1:不受影响-漏洞代码不存在
修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(23.08.5):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否
8.openEuler-24.03-LTS-SP1:否
===========================================================
郭梦琪
5个月前
CVE-2024-50144
openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
登录 后才可以发表评论
FileDragTip