Description
In the Linux kernel, the following vulnerability has been resolved:

drm/xe/dma-buf: handle empty bo and UAF races

There look to be some nasty races here when triggering the
invalidate_mappings hook:

1) We do xe_bo_alloc() followed by the attach, before the actual full bo
init step in xe_dma_buf_init_obj(). However the bo is visible on the
attachments list after the attach. This is bad since exporter driver,
say amdgpu, can at any time call back into our invalidate_mappings hook,
with an empty/bogus bo, leading to potential bugs/crashes.

2) Similar to 1) but here we get a UAF, when the invalidate_mappings
hook is triggered. For example, we get as far as xe_bo_init_locked()
but this fails in some way. But here the bo will be freed on error, but
we still have it attached from dma-buf pov, so if the
invalidate_mappings is now triggered then the bo we access is gone and
we trigger UAF and more bugs/crashes.

To fix this, move the attach step until after we actually have a fully
set up buffer object. Note that the bo is not published to userspace
until later, so not sure what the comment "Don't publish the bo
until we have a valid attachment", is referring to.

We have at least two different customers reporting hitting a NULL ptr
deref in evict_flags when importing something from amdgpu, followed by
triggering the evict flow. Hit rate is also pretty low, which would
hint at some kind of race, so something like 1) or 2) might explain
this.

v2:
- Shuffle the order of the ops slightly (no functional change)
- Improve the comment to better explain the ordering (Matt B)

(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)
Published: 2026-06-24
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw occurs while allocating and attaching buffer objects in the Linux kernel DRM Xe DMA subsystem. An empty or prematurely freed buffer can be exposed to the invalidate_mappings callback, which may then dereference a NULL or dangling pointer, causing a crash. The kernel panic resulting from this crash manifests as a denial‑of‑service for the affected system.

Affected Systems

Any Linux distribution running a kernel that contains the buggy drm/xe/dma-buf code before the commit that reorders the allocation and attachment steps. Systems that employ AMD GPU drivers (amdgpu) or other drivers interacting with the DRM Xe module are potentially affected.

Risk and Exploitability

The CVSS score is not provided. No publicly available exploitation data is listed and the vulnerability is not in CISA’s KEV catalog. Exploitation would require influence over the GPU driver or triggering a race condition in the kernel. Based on the description, it is inferred that a local attacker could potentially trigger this bug, but no remote exploitation path is documented. The primary impact is a kernel crash leading to denial‑of‑service; no additional privilege escalation is specified in the official description.

Generated by OpenCVE AI on June 24, 2026 at 20:18 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Install the latest stable kernel release that includes the reordered allocation and attachment logic for drm/xe/dma-buf
  • Continuously monitor /var/log/kern.log and dmesg for frequent "NULL ptr deref" or "evict" kernel messages indicating the race condition
  • If the affected GPU driver is not required for device operation, disable the module with modprobe -r amdgpu or by setting appropriate kernel boot parameters

Generated by OpenCVE AI on June 24, 2026 at 20:18 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 24 Jun 2026 20:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-476

Wed, 24 Jun 2026 17:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: drm/xe/dma-buf: handle empty bo and UAF races There look to be some nasty races here when triggering the invalidate_mappings hook: 1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes. 2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes. To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to. We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this. v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B) (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)
Title drm/xe/dma-buf: handle empty bo and UAF races
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-24T16:28:34.351Z

Reserved: 2026-06-09T07:44:35.372Z

Link: CVE-2026-52951

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-24T20:40:34Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

  • CWE-476

    NULL Pointer Dereference