Cloudanix VulnDB

CVE-2026-68266

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux graphics driver can let a logged-in user crash the whole computer or possibly take control of it.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free on a dma-buf exporter's reservation object when an imported sg BO creation fails before the importer holds a reference; subsequent asynchronous ttm_bo_delayed_delete locks the freed resv.

Why it matters to the business

Local users on Linux systems with affected graphics drivers can trigger kernel crashes or memory corruption, leading to denial of service and possible privilege escalation on graphics workloads.

How an attack unfolds

An attacker with local access creates an imported dma-buf BO via xe_bo_init_locked, forces dma_buf_dynamic_attach or ttm_bo_init_reserved to fail, then waits for the delayed-delete workqueue to dereference the now-freed exporter resv, producing a GP fault.

How to fix it

Apply the upstream fix that holds a dma-buf reference for the entire lifetime of imported BOs by taking the reference in xe_bo_init_locked before ttm_bo_init_reserved and releasing it in xe_ttm_bo_destroy; update to a kernel containing commit 3516f3fae6be.

How to confirm the fix worked

Verify the presence of the dma-buf reference acquisition in xe_bo_init_locked and the corresponding release in xe_ttm_bo_destroy; confirm no crash occurs on import failure paths and that kernel version or git commit matches the patched state.

Typical attack path

  1. Obtain local unprivileged access to a system running the vulnerable kernel
  2. Trigger creation of an imported dma-buf BO through graphics or userspace buffer import APIs
  3. Cause dma_buf_dynamic_attach or ttm_bo_init_reserved to fail after the BO has already stored the exporter resv pointer
  4. Allow the ttm delayed-delete workqueue to run and lock the stale reservation object
  5. Observe or exploit the resulting use-after-free for denial of service or code execution

How to detect it

Search kernel logs and crash dumps for the signature Oops involving general protection fault at mutex_can_spin_on_owner called from ttm_bo_delayed_delete workqueue; correlate with recent dma-buf or graphics buffer import activity.

  • Oops: general protection fault, probably for non-canonical address
  • Workqueue: ttm ttm_bo_delayed_delete [ttm]
  • RIP: mutex_can_spin_on_owner+0x3f/0xc0
  • bo->base.resv pointing at exporter resv after failed attach

What your security team should do

  • Prioritize kernel updates for systems exposing Intel Xe or similar DRM drivers to untrusted local users
  • Monitor for kernel oops involving mutex_can_spin_on_owner and ttm_bo_delayed_delete
  • Restrict unprivileged access to graphics buffer import interfaces until patches are deployed
  • Re-test graphics workloads after upgrade to ensure BO import paths no longer reference freed resv objects

The record

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)

Affected packages

Ecosystem Package Introduced Fixed