CVE-2026-46224

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel Intel Xe DRM graphics driver. In the xe_dma_buf_init_obj() error path, a pre-allocated buffer object is not freed when drm_gpuvm_resv_object_alloc() fails. A local user able to exercise the relevant GPU/DRM dma-buf import path can repeatedly trigger allocation failures and cause kernel memory/resource leakage, potentially degrading system performance or exhausting memory until the host becomes unstable or unavailable. The flaw does not directly provide confidentiality or integrity impact and is not a remote code execution issue.

Why it matters to the business

Systems running affected Linux kernels with the Xe graphics driver exposed to untrusted local users or workloads may be vulnerable to host instability or outage. The most relevant risk is service disruption on shared workstations, GPU-enabled compute nodes, CI/build infrastructure, desktops, or multi-user Linux servers where local users or containers can access DRM/GPU devices. EPSS is currently very low, it is not in CISA KEV, and no public exploit maturity is reported, so broad emergency response is not indicated; however, availability-sensitive systems should still receive routine kernel updates.

How an attack unfolds

An attacker first needs local code execution or an account on a system using an affected Linux kernel with the drm/xe driver. They then interact with the DRM/GPU dma-buf import functionality in a way that drives xe_gem_prime_import() into xe_dma_buf_init_obj(). By repeatedly causing or racing allocation failure conditions in drm_gpuvm_resv_object_alloc(), the vulnerable error path returns without freeing the pre-allocated storage buffer object. Repetition causes memory/resource leakage in kernel space. Over time, this can reduce available memory, trigger allocation failures elsewhere, degrade graphics/GPU functionality, or cause broader system instability or denial of service. Because the bug is local and availability-focused, successful exploitation generally depends on access to GPU device nodes and the ability to generate sufficient repeated operations.

How to fix it

Update to a Linux kernel build that includes the upstream fix from commit 78a6c5f899f22338bbf48b44fb8950409c5a69b9 or the equivalent fix from the relevant Linux distribution/vendor. Because no exact fixed package versions were provided, track distribution advisories for the affected kernel package and confirm the drm/xe fix is included. Where immediate patching is not possible, reduce exposure by restricting local access to GPU/DRM device nodes, limiting untrusted users and workloads on affected systems, disabling or avoiding use of the Xe driver where operationally feasible, and applying resource controls to untrusted workloads. Reboot into the updated kernel after installation; merely installing a kernel package is not sufficient if the host continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version and distribution changelog/advisory for the drm/xe fix. Validate that the patched source or vendor build includes the change that frees the storage buffer object on xe_dma_buf_init_obj() failure when drm_gpuvm_resv_object_alloc() fails. On source-based systems, verify the presence of the xe_bo_free(storage) handling in the relevant drm/xe code path. Confirm whether the Xe driver is loaded with tools such as lsmod and whether DRM devices are present under /dev/dri. For exposure validation, review permissions on /dev/dri/card* and /dev/dri/renderD* and determine whether untrusted local users or containers can access them. After remediation, reboot and verify the system is running the fixed kernel.

Typical attack path

1. Gain local access to an affected Linux system, either through a user account, local shell, compromised service, or workload/container with access to DRM/GPU device nodes.
2. Confirm the system is using an affected kernel build with the Intel Xe DRM driver enabled and accessible.
3. Open relevant DRM device interfaces such as /dev/dri/card* or /dev/dri/renderD* where permissions allow.
4. Trigger dma-buf/GEM PRIME import operations that reach xe_gem_prime_import() and xe_dma_buf_init_obj().
5. Induce allocation failure conditions around drm_gpuvm_resv_object_alloc() through resource pressure or repeated operations.
6. Repeat the operation to leak kernel buffer-object resources.
7. Continue until memory/resource exhaustion causes degraded performance, GPU/graphics failures, process failures, or host instability.

How to detect it

Detecting prior exploitation is difficult because this flaw is a kernel memory/resource leak and may not leave a unique log signature. Focus on evidence of local abuse of DRM/GPU interfaces combined with memory exhaustion or GPU driver instability. Review kernel logs, system journal, audit logs, and endpoint telemetry for repeated access to /dev/dri/card* or /dev/dri/renderD* by untrusted users or containers shortly before memory pressure, OOM killer activity, GPU reset messages, process failures, or host crashes. Investigate spikes in GPU/DRM ioctl activity, repeated process crashes involving graphics or compute workloads, and unexplained memory growth without a corresponding user-space process footprint. If auditd or eBPF telemetry is available, search for repeated opens/ioctls against DRM render nodes. In containerized environments, review runtime configuration and logs for workloads granted GPU device access. Because no public exploit artifacts or named threat actors are reported, detection should be behavior-based rather than IOC-only.

• /dev/dri/card
• /dev/dri/renderD
• drm/xe
• xe_dma_buf_init_obj
• xe_gem_prime_import
• drm_gpuvm_resv_object_alloc
• Out of memory
• oom-killer
• Killed process
• Memory allocation failure
• GPU HANG
• drm:
• xe

What your security team should do

• Prioritize patching affected GPU-enabled Linux systems that allow local multi-user access, untrusted workloads, containers with GPU passthrough, or shared compute usage.
• Update to a vendor kernel containing the upstream drm/xe memory-leak fix and reboot into the fixed kernel.
• Inventory systems using the Intel Xe DRM driver and identify those exposing /dev/dri devices to non-administrative users or containers.
• Restrict access to DRM/GPU device nodes to trusted users and workloads until patching is complete.
• Monitor affected systems for unexplained memory pressure, OOM events, GPU driver errors, or repeated crashes that could indicate attempted denial of service.
• For high-availability systems, consider temporarily disabling untrusted GPU access or migrating workloads away from affected kernels until updates are applied.
• Track Linux distribution advisories because fixed package names and versions vary by vendor and were not provided in the input.
• Do not treat this as a remote compromise indicator by itself; focus response on local abuse, availability impact, and kernel update hygiene.