Linux: Use After Free
CVE-2024-26939 is a high-severity use after free vulnerability in Linux, with a CVSS 3.1 base score of 7.0 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 704edc9252f4988ae1ad7dafa23d0db8d90d7190, 5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5, 59b2626dd8c8a2e13f18054b3530e0c00073d79f as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.25% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 704edc9252f4988ae1ad7dafa23d0db8d90d7190 or 5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5 or 59b2626dd8c8a2e13f18054b3530e0c00073d79f or 0e45882ca829b26b915162e8e86dbb1095768e9e, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.1.88 or 6.6.29 or 6.8.3, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | d93939730347360db0afe6a4367451b6f84ab7b1 up to, but not including, 704edc9252f4988ae1ad7dafa23d0db8d90d7190; d93939730347360db0afe6a4367451b6f84ab7b1 up to, but not including, 5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5; d93939730347360db0afe6a4367451b6f84ab7b1 up to, but not including, 59b2626dd8c8a2e13f18054b3530e0c00073d79f; d93939730347360db0afe6a4367451b6f84ab7b1 up to, but not including, 0e45882ca829b26b915162e8e86dbb1095768e9e; 5.19 | 704edc9252f4988ae1ad7dafa23d0db8d90d7190, 5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5, 59b2626dd8c8a2e13f18054b3530e0c00073d79f, 0e45882ca829b26b915162e8e86dbb1095768e9e |
| Linux | Linux Kernel | 5.19 up to, but not including, 6.1.88; 6.2 up to, but not including, 6.6.29; 6.7 up to, but not including, 6.8.3; 6.9 | 6.1.88, 6.6.29, 6.8.3 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- HighSuccess depends on conditions outside the attacker's control.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by NVD.
| Scoring system | Score | Severity | Scored by |
|---|---|---|---|
| CVSS 3.1 | 7.8 | High | CNA |
| CVSS 3.1 | 7.0 | High | NVD |
Official description
In the Linux kernel, the following vulnerability has been resolved: drm/i915/vma: Fix UAF on destroy against retire race Object debugging tools were sporadically reporting illegal attempts to free 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 is deactivating the VMA inside __active_retire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of 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 from being used, e.g. from __i915_vma_retire() called at the end of __active_retire(), after that VMA has been already freed by a concurrent i915_vma_destroy() on return from the i915_active_fini(). Then, we should rather fix the issue at the VMA level, not in i915_active. Since __i915_vma_parked() is called from __gt_park() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for __active_retire() to complete before that wakeref is released and 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() from a 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 a bug 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 active intel_context for a GT associated with its VM, and indirectly on that intel_context's engine wakeref if the engine belongs to the same GT as the VMA'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 goes idle. Since __i915_vma_retire() may be called from atomic contexts, use async 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---
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory belongs to the code that operates on the new pointer.
How developers prevent this class of flaw
- Choose a language that provides automatic memory management.
- When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Recent Use After Free vulnerabilities
- 9.8 Critical severity
- 8.8 High severity
- 8.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
Spotted an error? Tell us.