Linux kernel drm/xe: reference leaks when a submission sync object fails to parse

CVSS 5.5CVE-2026-43395NVIDIA / GPU stackcurated

Impact

xe_sync_entry_parse() can take references on a syncobj, a dma-fence, a chain fence or a user fence and then hit a later failure path that returned directly, leaking those references. Anything that can issue Xe submission ioctls can repeat the failing path and leak kernel objects indefinitely, ending in memory exhaustion on the node. On an Intel Data Center GPU host that is a slow availability loss on a machine that has to be drained and rebooted to recover, and on a shared node one tenant can degrade every other tenant on the same host. Confidentiality and integrity are not affected per the published vector (AV:L/C:N/I:N/A:H).

Who can reach it

Local, authenticated: any user or container that holds an Xe DRM render node (/dev/dri/renderD*) and can submit exec/sync ioctls. Not reachable remotely and not reachable on hosts without the xe driver loaded.

What to do

Take the stable kernel update that routes these error paths through the common free_sync label (commit f939bdd9207a cherry-picked to stable); the fix is a kernel patch, so each node must be rebooted onto the new kernel, which means draining GPU workloads first. No vendor mitigation is published other than restricting access to the Xe render nodes.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-43395 https://git.kernel.org/stable/c/f0af63ffa06306f12592cd3919fad6957b425e1b https://git.kernel.org/stable/c/af65cd1853599394b94201c08bed7a46717db478

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.