CVE-2026-68266: drm/xe: Hold a dma-buf reference for imported BOs

Published Aug 10, 2026
·
Updated

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 ttmbotypesg BO whose reservation object is the exporter's dmabuf->resv. The importer, however, only takes a dma-buf reference after a successful dmabufdynamicattach(). 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 ttmbodelayeddelete [ttm] RIP: 0010:mutexcanspinonowner+0x3f/0xc0

This can be reached on two paths:

- dmabufdynamicattach() fails, or - ttmboinitreserved() 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 ttmbodelayeddelete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed.

Take the dma-buf reference in xeboinitlocked(), before ttmboinitreserved(), so it also covers a creation failure there, and release it in xettmbodestroy(). 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 dmabufdynamicattach() succeeds. - Attach with importerpriv == NULL and make invalidatemappings ignore incomplete imports.

v3: - Dropped the xe-side reordering approach since importerpriv must be valid when dmabufdynamicattach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on importattach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch.

v4: - Moved importattach check to after dmaresvcopyfences() 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 xeboinitlocked() before ttmboinitreserved() 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 ttmbopipelinegutting() 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 Software

1 affected component
Linux Kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade drm/xe to a version that resolves this vulnerability.

    Patch https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2
  2. Configuration

    In drm/xe, for imported BOs, take a dma-buf reference in xe_bo_init_locked() before the importer creates the imported BO (i.e., before any point where the imported sg BO lifetime could otherwise outlive the exporter’s dma_buf-resv). This ensures the exporter cannot be freed while the imported BO still references the exporter’s resv.

    dma-buf dynamic attach / importer attach flow (drm/xe) dma_buf reference acquisition timing for imported BOs = Take the dma-buf reference in xe_bo_init_locked() before creating/initializing the imported BO
  3. Configuration

    When attaching imported BOs, attach with importer_priv == NULL and ensure invalidate_mappings ignores this case.

    TTM reservation/invalidate mappings for imported BOs invalidate_mappings behavior when importer_priv == NULL = Make invalidate_mappings ignore when importer_priv == NULL and attach using importer_priv == NULL
  4. Configuration

    Apply the drm/ttm/xe off-LRU approach for imported sg BOs: keep imported sg BOs off the LRU before attach so they are not visible (and thus not asynchronously torn down) before the attach/import flow is complete.

    TTM imported sg BO lifecycle / LRU placement LRU visibility timing for imported sg BOs = Keep imported sg BOs off the LRU before attach

Event History

Aug 10, 2026
CVE Published
via MITRE·12:01 PM
Data Sourced
via MITRE·12:01 PM
Description
Data Sourced
via NVD·01:20 PM
Description
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-68266?

CVE-2026-68266 has a risk score of 34, indicating a moderate severity level.

2

How do I fix CVE-2026-68266?

To fix CVE-2026-68266, ensure you update your Linux kernel to the latest version where the vulnerability has been patched.

3

What type of vulnerability is CVE-2026-68266?

CVE-2026-68266 is classified as a Use After Free vulnerability.

4

In which software is CVE-2026-68266 found?

CVE-2026-68266 is found in the Linux kernel.

5

What does CVE-2026-68266 affect?

CVE-2026-68266 affects the handling of imported dma-buf buffer objects in the Linux kernel.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203