GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel Intel Xe dma-buf: attaching before init exposes an empty or freed buffer object to the exporter

CVSS 7.8CVE-2026-52951NVIDIA / GPU stackcurated

Impact

Xe attached the imported dma-buf before the buffer object was fully initialised, so the object was visible on the exporter's attachment list while still empty - and if init then failed, the object was freed while remaining attached. Either way the exporting driver can call back into Xe's invalidate_mappings hook and operate on a bogus or already-freed object, giving a NULL dereference or a use-after-free. The upstream commit notes two separate customers hitting a NULL pointer dereference in evict_flags when importing from amdgpu and then triggering eviction, with a low hit rate consistent with a race. Mixed-vendor GPU nodes - Intel Xe importing from amdgpu - are exactly where this fires, and the crash lands in the host kernel, taking the node and every pod on it down. The fix moves the attach until after the object is fully set up.

Who can reach it

Local, authenticated. A tenant with render-node access on a host running drm/xe who can import a dma-buf from another driver and then provoke eviction. Triggering it reliably needs a race, so expect intermittent crashes rather than a clean repro.

What to do

Update to a fixed stable or distribution kernel and reboot the affected nodes. Red Hat tracks it for RHEL 6 through 10. There is no configuration mitigation; cross-driver dma-buf sharing is a legitimate workload pattern. If you are already chasing unexplained evict_flags NULL dereferences on Intel Xe nodes, this is a strong candidate for the cause.

References

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.