Skip to main content

CVE-2024-26939: Vulnerability in Linux Linux

High
VulnerabilityCVE-2024-26939cvecve-2024-26939
Published: Wed May 01 2024 (05/01/2024, 05:17:44 UTC)
Source: CVE
Vendor/Project: Linux
Product: 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

AILast updated: 06/29/2025, 13:25:47 UTC

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.

Need more detailed analysis?Get Pro

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

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats