CVE-2026-68266 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Hold a dma-buf reference for imported BOs
An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free:
Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm]
RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0
This can be reached on two paths:
- dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation.
In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed.
Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path.
v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports.
v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch.
v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas).
v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4.
v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/
v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas)
(cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability described in this CVE relates to a use-after-free condition within the Linux kernel's graphics subsystem, specifically within the Direct Rendering Manager (DRM) and the Transportable Texture Mapping (TTM) framework. The issue occurs during the handling of imported dma-buf buffer objects (BOs) in the Intel xe driver, where an improper reference counting mechanism leads to a scenario where the exporter's reservation object can be freed while the importer still holds a reference to it. This flaw is categorized under CWE-416, which deals with use-after-free conditions, and aligns with ATT&CK technique T1059.008 for privilege escalation through kernel exploits.
The technical root cause stems from how imported dma-buf BOs are initialized within the xe driver. When an imported BO is created, it is set up as a ttm_bo_type_sg BO with its reservation object pointing to the exporter's dma_buf->resv. The importer only acquires a reference to the dma-buf after a successful dma_buf_dynamic_attach() call, but this reference is not taken early enough in the process. This creates a window where the exporter can be freed while the BO still references its reservation object, leading to a use-after-free upon later access to the reservation object during asynchronous cleanup via ttm_bo_delayed_delete(). The kernel oops message indicates a general protection fault at mutex_can_spin_on_owner, which is a clear indicator of accessing freed memory.
The vulnerability can be triggered through two primary failure paths during BO creation: when dma_buf_dynamic_attach() fails or when ttm_bo_init_reserved() fails during the initialization process. Both scenarios leave the BO with bo->base.resv pointing to the exporter's reservation object, but without proper reference counting, the exporter may be freed before the BO is destroyed. The asynchronous nature of ttm_bo_delayed_delete(), which locks the reservation object after a potential delay, increases the likelihood of this race condition occurring.
The fix implemented addresses this by taking the dma-buf reference earlier in the process, specifically within xe_bo_init_locked() before calling ttm_bo_init_reserved(). This ensures that the reference covers not just successful creation but also handles failures during TTM initialization. The reference is then properly released in xe_ttm_bo_destroy(), maintaining it for the entire lifetime of the BO. This approach resolves the race condition by ensuring that the shared reservation object remains valid as long as the BO exists, preventing the use-after-free scenario described in the vulnerability report.
This fix represents a targeted solution that avoids the complexity of reordering BO creation or implementing separate off-LRU handling approaches that were previously considered but ultimately deemed insufficient or problematic. The approach taken aligns with the principle of maintaining consistent reference counting throughout the object lifecycle and ensures that the shared reservation object cannot be freed while still referenced by the imported BO. The solution is implemented as a single patch for the xe driver without requiring changes to the TTM subsystem, making it a focused and less disruptive fix. The approach also addresses similar issues in other drivers like AMDGPU through a unified TTM patch, demonstrating its broader applicability to the graphics driver ecosystem.
The vulnerability highlights the critical importance of proper reference counting in kernel-level memory management, especially when dealing with shared objects across different subsystems. In the context of graphics drivers, where complex object lifecycles and inter-driver dependencies exist, such flaws can lead to system crashes or potential privilege escalation attacks. The fix demonstrates a robust approach to managing shared resources by ensuring that all references are properly accounted for throughout the entire object lifetime, preventing the scenario where one subsystem frees an object while another still holds references to it. This type of vulnerability is particularly concerning in graphics contexts where kernel memory corruption can lead to denial-of-service or potentially more serious security implications depending on how the graphics subsystem integrates with other system components.
This particular flaw underscores the complexities inherent in managing shared resources within kernel drivers and the importance of careful synchronization when dealing with asynchronous operations. The fix's emphasis on maintaining references for the complete object lifetime rather than relying on complex state tracking mechanisms provides a more reliable solution that is less prone to similar issues in future development. The approach taken also emphasizes the importance of considering all possible failure paths during object initialization, ensuring that reference counting is maintained even when operations fail partway through the process. This aligns with industry best practices for kernel-level memory management and demonstrates how proper architectural design can prevent subtle but serious vulnerabilities from manifesting in production systems.
The vulnerability's resolution through a single dma-buf reference management approach rather than more complex solutions provides a clean and maintainable fix that reduces the potential for introducing new bugs. The iterative development process shown in the patch versions indicates thorough testing and refinement, with various approaches being evaluated before settling on the final solution. This process demonstrates how kernel security vulnerabilities require careful analysis and testing to ensure that fixes don't introduce regressions or additional complexity while still addressing the core issue effectively. The final approach's focus on holding references for the entire BO lifetime provides a robust defense against similar race conditions in other parts of the graphics subsystem where shared reservation objects may be involved.