Linux kernel drm/xe: OA config ioctl leaks sync entries and fence references when the config emit fails
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
Related entries
- Linux kernel amdgpu: unvalidated UVD decode message fields overflow the DPB size calculationCVE-2026-80908 · Linux kernel amdgpu UVD (decode message field validation)Unscored
- GPU / accelerator firmware (VBIOS, GSP, NVSwitch): GPU-resident firmware sits below the host OS and is not coveredNCVD-0000-012-gpu-accelerator-firmware-vbios-g · GPU / accelerator firmware (VBIOS, GSP, NVSwitch)Unscored
- NVIDIA Multi-Instance GPU (MIG) partitioning: MIG gives each instance its own SM slice, L2 slice, memory slice andNCVD-2020-001-nvidia-multi-instance-gpu-mig-pa · NVIDIA Multi-Instance GPU (MIG) partitioningUnscored
- NVIDIA Multi-Instance GPU (MIG) partitioning: MIG gives each instance its own SM slice, L2 slice, memory slice andNCVD-2020-003-nvidia-multi-instance-gpu-mig-pa · NVIDIA Multi-Instance GPU (MIG) partitioningUnscored
- Integrated GPU graphics data compression (Intel, AMD, Apple, Arm, Qualcomm, NVIDIA): GPUs apply data-dependent losslessNCVD-2023-003-integrated-gpu-graphics-data-com · Integrated GPU graphics data compression (Intel, AMD, Apple, Arm, Qualcomm, NVIDIA)Unscored
- NVIDIA Confidential Computing (H100/H200/B100/B200/GB200) - CC-DevTools operating mode: NVIDIA GPU confidentialNCVD-2023-004-nvidia-confidential-computing-h1 · NVIDIA Confidential Computing (H100/H200/B100/B200/GB200) - CC-DevTools operating modeUnscored
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.