HIGH Introduced in 6.8
drm/xe DmaBuf UAF Race
CVE-2026-52951
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.5HIGH
01Description
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)
02KernelScan AI Analysis
Risk summary
A race condition in the Intel Xe GPU driver's DMA-buf import path allows a concurrent invalidate_mappings callback from an exporting driver (e.g., amdgpu) to access a partially initialized or already-freed buffer object. A local user with access to GPU devices that share DMA-buf handles between drivers (e.g., amdgpu exporting to xe) can trigger a use-after-free or NULL pointer dereference, potentially leading to kernel crashes or privilege escalation. The low hit rate and cross-driver nature make this a hard-to-trigger but serious kernel memory safety issue.
Vulnerability analysis
The root cause is a TOCTOU/ordering race in xe_gem_prime_import(): the buffer object (bo) was allocated with xe_bo_alloc() and then immediately attached to the DMA-buf (making it visible on the attachments list) before the bo was fully initialized via xe_dma_buf_init_obj(). This creates two race windows: (1) after attach but before init completes, the exporting driver can invoke the invalidate_mappings callback on an empty/uninitialized bo, causing NULL pointer dereferences; (2) if xe_dma_buf_init_obj() fails and frees the bo, but the attachment still exists, a subsequent invalidate_mappings callback accesses the freed bo memory (use-after-free). The fix reorders operations so that xe_dma_buf_init_obj() is called first to fully initialize the bo before dma_buf_attach() is called, ensuring the bo is always in a valid state when it becomes globally visible via the attachments list. The error path is also corrected to use xe_bo_put() instead of xe_bo_free() since init_obj takes ownership. This is reachable by any local user with access to a DRM device file descriptor that can perform cross-driver DMA-buf sharing (e.g., importing an amdgpu buffer into xe), which typically requires only user-level GPU access (no special capabilities needed beyond device file access).
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 6.8 | 6.12.91 | 9894731e5130 |
| 6.18 | 6.8 | 6.18.33 | 20a99ea1e2fd |
| 7.0 | 6.8 | 7.0.10 | c473ae25421f |
| mainline | 6.8 | 7.1 | 981bedbbe613 |