CVE-2024-26939

一、漏洞信息
 漏洞编号：[CVE-2024-26939](https://nvd.nist.gov/vuln/detail/CVE-2024-26939)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：6.1.19,6.4.0
 CVSS V3.0分值：
  BaseScore：0.0 None
  Vector：CVSS：3.0/
 漏洞简述：
  A vulnerability has been found in Linux Kernel up to 6.1.87/6.6.28/6.8.2/6.9-rc1 (Operating System) and classified as critical.The CWE definition for the vulnerability is CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.1.88, 6.6.29, 6.8.3 or 6.9-rc2 eliminates this vulnerability. Applying the patch 704edc9252f4/5e3eb862df9f/59b2626dd8c8/0e45882ca829 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.
 漏洞公开时间：2024-05-01 00:00:00
 漏洞创建时间：2024-05-01 07:20:58
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2024-26939
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
|  | https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e |  |
|  | https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f |  |
|  | https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5 |  |
|  | https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190 |  |
|  | https://www.cve.org/CVERecord?id=CVE-2024-26939 |  |
|  | https://git.kernel.org/linus/0e45882ca829b26b915162e8e86dbb1095768e9e |  |
|  | https://ubuntu.com/security/notices/USN-6816-1 |  |
|  | https://ubuntu.com/security/notices/USN-6817-1 |  |
|  | https://ubuntu.com/security/notices/USN-6817-2 |  |
|  | https://ubuntu.com/security/notices/USN-6817-3 |  |
|  | https://ubuntu.com/security/notices/USN-6878-1 |  |

</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  openBrain开源漏洞感知系统
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
|  | https://github.com/torvalds/linux/commit/0e45882ca829b26b915162e | https://github.com/torvalds/linux/commit/0e45882ca829b26b915162e8e86dbb1095768e9e.patch |  | ljqc |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
    In the Linux kernel, the following vulnerability has been resolved:drm/i915/vma: Fix UAF on destroy against retire raceObject debugging tools were sporadically reporting illegal attempts tofree a still active i915 VMA object when parking a GT believed to be idle.[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915][161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0...[161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1[161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022[161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915][161.360592] RIP: 0010:debug_print_object+0x80/0xb0...[161.361347] debug_object_free+0xeb/0x110[161.361362] i915_active_fini+0x14/0x130 [i915][161.361866] release_references+0xfe/0x1f0 [i915][161.362543] i915_vma_parked+0x1db/0x380 [i915][161.363129] __gt_park+0x121/0x230 [i915][161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915]That has been tracked down to be happening when another thread isdeactivating the VMA inside __active_retire() helper, after the VMA sactive counter has been already decremented to 0, but before deactivationof the VMA s object is reported to the object debugging tool.We could prevent from that race by serializing i915_active_fini() with__active_retire() via ref->tree_lock, but that wouldn t stop the VMA frombeing used, e.g. from __i915_vma_retire() called at the end of__active_retire(), after that VMA has been already freed by a concurrenti915_vma_destroy() on return from the i915_active_fini().  Then, we shouldrather fix the issue at the VMA level, not in i915_active.Since __i915_vma_parked() is called from __gt_park() on last put of theGT s wakeref, the issue could be addressed by holding the GT wakeref longenough for __active_retire() to complete before that wakeref is releasedand the GT parked.I believe the issue was introduced by commit d93939730347 ( drm/i915:Remove the vma refcount ) which moved a call to i915_active_fini() froma dropped i915_vma_release(), called on last put of the removed VMA kref,to i915_vma_parked() processing path called on last put of a GT wakeref.However, its visibility to the object debugging tool was suppressed by abug in i915_active that was fixed two weeks later with commit e92eb246feb9( drm/i915/active: Fix missing debug object activation ).A VMA associated with a request doesn t acquire a GT wakeref by itself.Instead, it depends on a wakeref held directly by the request s activeintel_context for a GT associated with its VM, and indirectly on thatintel_context s engine wakeref if the engine belongs to the same GT as theVMA s VM.  Those wakerefs are released asynchronously to VMA deactivation.Fix the issue by getting a wakeref for the VMA s GT when activating it,and putting that wakeref only after the VMA is deactivated.  However,exclude global GTT from that processing path, otherwise the GPU never goesidle.  Since __i915_vma_retire() may be called from atomic contexts, useasync variant of wakeref put.  Also, to avoid circular locking dependency,take care of acquiring the wakeref before VM mutex when both are needed.v7: Add inline comments with justifications for:    - using untracked variants of intel_gt_pm_get/put() (Nirmoy),    - using async variant of _put(),    - not getting the wakeref in case of a global GTT,    - always getting the first wakeref outside vm->mutex.v6: Since __i915_vma_active/retire() callbacks are not serialized, storing    a wakeref tracking handle inside struct i915_vma is not safe, and    there is no other good place for that.  Use untracked variants of    intel_gt_pm_get/put_async().v5: Replace  tile  with  GT  across commit description (Rodrigo),  - ---truncated--- 
 openEuler评分：
  7.8
 Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
 受影响版本排查(受影响/不受影响)：
  1.openEuler-20.03-LTS-SP1:不受影响
2.openEuler-20.03-LTS-SP4:不受影响
3.openEuler-22.03-LTS:不受影响
4.openEuler-22.03-LTS-SP1:不受影响
5.openEuler-22.03-LTS-SP2:不受影响
6.openEuler-22.03-LTS-SP3:不受影响
7.openEuler-22.03-LTS-SP4:不受影响
8.master:不受影响
9.openEuler-22.03-LTS-Next:不受影响
10.openEuler-24.03-LTS:不受影响
11.openEuler-24.03-LTS-Next:不受影响

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

原因说明：
  1.master:
2.openEuler-20.03-LTS-SP4:
3.openEuler-22.03-LTS-SP1:
4.openEuler-22.03-LTS-SP3:
5.openEuler-22.03-LTS-SP4:
6.openEuler-24.03-LTS:
7.openEuler-24.03-LTS-Next:
8.openEuler-24.03-LTS-SP1:

src-openEuler/kernel
Closed

Content Risk Flag

Comments (4)

src-openEuler/kernelClosed .gitee-modal { width: 500px !important; }

Content Risk Flag

CVE-2024-26939

Comments (4)

Search

src-openEuler/kernel
Closed