GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel Intel Xe driver: dma-buf attachment leaked when GEM prime import fails

CVSS 7.8CVE-2026-46201NVIDIA / GPU stackcurated

Impact

When xe_dma_buf_init_obj() fails during xe_gem_prime_import(), the attachment created by dma_buf_dynamic_attach() is never detached. The failed import leaves a dangling attachment on the exporter's attachment list while the importing buffer object has already been freed, so the exporter can later walk into state that no longer belongs to anyone. On a node with Intel Data Center GPUs this matters where buffers are shared across drivers or processes - a tenant that can repeatedly fail an import accumulates stale attachments and can push the GPU driver into an inconsistent state that only a reboot clears. The record establishes the leak and the error-path ordering; it does not demonstrate a working use-after-free, so do not read this as proven code execution.

Who can reach it

Local, authenticated. A user or container holding a /dev/dri render node on an Intel Xe GPU who can trigger a failing prime (dma-buf) import. No network path.

What to do

Move to a fixed stable kernel and reboot the affected GPU nodes. Only hosts running the drm/xe driver for Intel GPUs are in scope; NVIDIA and AMD fleets are not. There is no runtime mitigation beyond withholding render-node access from untrusted workloads, which usually defeats the point of the node.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-46201https://git.kernel.org/stable/c/0afa8b1ef582ecf6fb04097fd356f8741e5005edhttps://git.kernel.org/stable/c/111ab678471bf1f90d078d5513bb086b70596c3chttps://git.kernel.org/stable/c/d394669e194936d7ce15284a24a5ae334c4c5b74

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.