Linux kernel drm/xe: OA config ioctl leaks sync entries and fence references when the config emit fails

UnscoredCVE-2026-80903NVIDIA / GPU stackcurated

Impact

xe_oa_emit_oa_config() only frees the parsed sync entries and the syncs array on its success path. When it fails early - fence allocation, config buffer allocation or batch submission - xe_oa_config_locked() propagates the error without cleaning up, and the next config ioctl overwrites stream->syncs, so the array and the dma-fence references it holds become unreachable for good. A local process that can open an OA stream and repeatedly drive the config ioctl into that failure path grows unreclaimable kernel memory and pins fences that never drop. The Xe driver is what Intel Data Center GPU Max parts run on, so this lands on the accelerator nodes rather than on workstations; the practical consequence is kernel memory exhaustion on a node that only a reboot clears. The commits describe a leak only - no memory corruption or privilege escalation is claimed, and profiling ioctls are not something most tenant workloads touch.

Who can reach it

Local user on the GPU node holding an open DRM device and able to open an OA stream on it - i.e. a tenant with a GPU container that has the render node passed through. Authentication to the host is required; nothing is reachable over the network.

What to do

Take the stable kernel containing the fix (backported across several stable branches, see the git.kernel.org links) and reboot. Each GPU node has to be drained and rebooted, since the leak lives in the loaded driver and there is no runtime mitigation short of denying OA stream access. No vendor advisory beyond the kernel stable commits exists in the record, and no fixed release version is stated there.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-80903 https://git.kernel.org/stable/c/027150e24e173a5dffe7f5ab3a6600618f634da2 https://git.kernel.org/stable/c/8d33c4987cd162527375a3905017ae129ba7c3fe https://git.kernel.org/stable/c/948f346fe36e1d02353c3d61b1f6b66c6af91996

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.