CVE-2024-26939: Vulnerability in Linux Linux
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---
AI Analysis
Technical Summary
CVE-2024-26939 is a use-after-free (UAF) vulnerability in the Linux kernel's Intel i915 graphics driver, specifically within the management of virtual memory areas (VMAs) in the Direct Rendering Manager (DRM) subsystem. The flaw arises due to a race condition between the deactivation and destruction of i915 VMA objects. When the GPU's Graphics Technology (GT) is parked (considered idle), the driver attempts to free VMA objects. However, concurrent threads may still be accessing or deactivating these VMAs, leading to illegal attempts to free an active object. This results from improper synchronization between the functions i915_active_fini() and __active_retire(), which manage the lifecycle of active VMAs. The root cause was introduced by a prior commit that removed VMA reference counting and shifted the release logic to the GT parking path, but without adequate locking or wakeref (wake reference) management. The fix involves acquiring and holding a wakeref for the GT during VMA activation and only releasing it after deactivation completes, preventing premature freeing. This wakeref management excludes the global Graphics Translation Table (GTT) to avoid GPU idle issues and uses asynchronous wakeref release to accommodate atomic contexts. The vulnerability is classified under CWE-416 (Use After Free) and does not currently have known exploits in the wild. It affects Linux kernel versions containing the problematic commit d93939730347 and related revisions. The issue can cause kernel warnings, potential system instability, and may be exploitable to cause denial of service or potentially escalate privileges if an attacker can trigger the race condition.
Potential Impact
For European organizations relying on Linux systems with Intel integrated graphics using the i915 driver—common in desktops, laptops, and servers—the vulnerability poses a risk of kernel crashes or system instability due to use-after-free conditions. This could lead to denial of service (DoS) scenarios, impacting availability of critical systems. While no public exploits are known, the complexity of the race condition and the kernel-level nature of the flaw mean that sophisticated attackers could potentially leverage it for privilege escalation or to compromise system integrity. Organizations in sectors with high reliance on Linux-based infrastructure, such as finance, telecommunications, research institutions, and government agencies, could face operational disruptions. Additionally, systems running workloads involving GPU acceleration or graphics rendering may be more exposed. The vulnerability's exploitation requires triggering specific GPU driver code paths, so environments with Intel integrated GPUs are primarily affected. Given the widespread use of Linux in European IT environments and the prevalence of Intel hardware, the threat is significant but somewhat limited to affected hardware and kernel versions.
Mitigation Recommendations
1. Apply the official Linux kernel patches that address CVE-2024-26939 as soon as they become available from trusted sources such as the Linux kernel mailing list or vendor security advisories. 2. For distributions that provide backported fixes, promptly update the kernel packages to incorporate the fix. 3. In environments where immediate patching is not feasible, consider disabling or limiting GPU-intensive workloads that rely on the i915 driver to reduce exposure. 4. Monitor system logs for kernel warnings related to i915 VMA objects or debug object free errors, which may indicate attempts to trigger the vulnerability. 5. Employ kernel live patching solutions where supported to minimize downtime during remediation. 6. Coordinate with hardware vendors and Linux distribution maintainers to ensure timely updates and verify that the fix is included in future kernel releases. 7. Implement strict access controls and monitoring on systems with Intel integrated GPUs to detect anomalous behavior that might exploit this race condition. 8. Avoid running untrusted code or workloads that could trigger complex GPU driver interactions on vulnerable systems until patched.
Affected Countries
Germany, France, United Kingdom, Netherlands, Italy, Spain, Poland, Sweden, Belgium, Finland
CVE-2024-26939: Vulnerability in Linux Linux
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---
AI-Powered Analysis
Technical Analysis
CVE-2024-26939 is a use-after-free (UAF) vulnerability in the Linux kernel's Intel i915 graphics driver, specifically within the management of virtual memory areas (VMAs) in the Direct Rendering Manager (DRM) subsystem. The flaw arises due to a race condition between the deactivation and destruction of i915 VMA objects. When the GPU's Graphics Technology (GT) is parked (considered idle), the driver attempts to free VMA objects. However, concurrent threads may still be accessing or deactivating these VMAs, leading to illegal attempts to free an active object. This results from improper synchronization between the functions i915_active_fini() and __active_retire(), which manage the lifecycle of active VMAs. The root cause was introduced by a prior commit that removed VMA reference counting and shifted the release logic to the GT parking path, but without adequate locking or wakeref (wake reference) management. The fix involves acquiring and holding a wakeref for the GT during VMA activation and only releasing it after deactivation completes, preventing premature freeing. This wakeref management excludes the global Graphics Translation Table (GTT) to avoid GPU idle issues and uses asynchronous wakeref release to accommodate atomic contexts. The vulnerability is classified under CWE-416 (Use After Free) and does not currently have known exploits in the wild. It affects Linux kernel versions containing the problematic commit d93939730347 and related revisions. The issue can cause kernel warnings, potential system instability, and may be exploitable to cause denial of service or potentially escalate privileges if an attacker can trigger the race condition.
Potential Impact
For European organizations relying on Linux systems with Intel integrated graphics using the i915 driver—common in desktops, laptops, and servers—the vulnerability poses a risk of kernel crashes or system instability due to use-after-free conditions. This could lead to denial of service (DoS) scenarios, impacting availability of critical systems. While no public exploits are known, the complexity of the race condition and the kernel-level nature of the flaw mean that sophisticated attackers could potentially leverage it for privilege escalation or to compromise system integrity. Organizations in sectors with high reliance on Linux-based infrastructure, such as finance, telecommunications, research institutions, and government agencies, could face operational disruptions. Additionally, systems running workloads involving GPU acceleration or graphics rendering may be more exposed. The vulnerability's exploitation requires triggering specific GPU driver code paths, so environments with Intel integrated GPUs are primarily affected. Given the widespread use of Linux in European IT environments and the prevalence of Intel hardware, the threat is significant but somewhat limited to affected hardware and kernel versions.
Mitigation Recommendations
1. Apply the official Linux kernel patches that address CVE-2024-26939 as soon as they become available from trusted sources such as the Linux kernel mailing list or vendor security advisories. 2. For distributions that provide backported fixes, promptly update the kernel packages to incorporate the fix. 3. In environments where immediate patching is not feasible, consider disabling or limiting GPU-intensive workloads that rely on the i915 driver to reduce exposure. 4. Monitor system logs for kernel warnings related to i915 VMA objects or debug object free errors, which may indicate attempts to trigger the vulnerability. 5. Employ kernel live patching solutions where supported to minimize downtime during remediation. 6. Coordinate with hardware vendors and Linux distribution maintainers to ensure timely updates and verify that the fix is included in future kernel releases. 7. Implement strict access controls and monitoring on systems with Intel integrated GPUs to detect anomalous behavior that might exploit this race condition. 8. Avoid running untrusted code or workloads that could trigger complex GPU driver interactions on vulnerable systems until patched.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-02-19T14:20:24.196Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9829c4522896dcbe2ec4
Added to database: 5/21/2025, 9:08:57 AM
Last enriched: 6/29/2025, 1:25:47 PM
Last updated: 8/8/2025, 4:51:09 AM
Views: 12
Related Threats
CVE-2025-8690: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in addix Simple Responsive Slider
MediumCVE-2025-8688: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in ebernstein Inline Stock Quotes
MediumCVE-2025-8685: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in emilien Wp chart generator
MediumCVE-2025-8621: CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) in odn Mosaic Generator
MediumCVE-2025-8568: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in prabode GMap Generator
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.