CVE-2026-46201

What it actually does

This is a local Linux kernel flaw in the DRM Xe graphics driver’s dma-buf import path. If xe_dma_buf_init_obj() fails after dma_buf_dynamic_attach() succeeds, the driver returns an error without detaching the dma-buf attachment. That attachment leak can leave kernel objects and references behind across repeated failure paths, creating a kernel resource/lifetime-management condition that may be abused by a local low-privileged user with access to the Xe DRM device. The assigned CVSS indicates possible high confidentiality, integrity, and availability impact, but exploitation requires local access and there is no known public exploit maturity in the provided data.

Why it matters to the business

Systems using the Linux kernel with the Intel Xe DRM driver may be exposed to local privilege-boundary risk from users, workloads, or containers that can access GPU/DRM device nodes. The most likely operational outcomes are host instability, denial of service, or a local compromise path on shared workstations, GPU-enabled servers, CI runners, VDI hosts, and container platforms that expose /dev/dri devices. This issue is not listed in CISA KEV, is not marked as ransomware-associated, and has a very low EPSS score, so it is lower internet-scale urgency than remotely exploitable flaws, but it should still be prioritized where untrusted local users or GPU-pass-through workloads are present.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user or inside a workload that has access to the affected DRM Xe device. They then interact with the graphics subsystem through normal device interfaces, attempting dma-buf import operations designed to make dma_buf_dynamic_attach() succeed while forcing xe_dma_buf_init_obj() to fail. Because the vulnerable error path does not call dma_buf_detach(), each failed attempt can leave a stale attachment/reference behind. By repeating this operation, the attacker may consume kernel resources, destabilize the graphics driver or host, and potentially manipulate kernel object lifetime behavior. Depending on kernel configuration, driver state, and available primitives, this kind of reference/attachment leak may contribute to information disclosure, integrity impact, or denial of service, but reliable exploitation would require local access and kernel/driver-specific technique.

How to fix it

Upgrade to a vendor-supplied Linux kernel version that includes the upstream fix for the Xe driver attachment leak. Where available, verify that the kernel package includes the change titled "drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import()" or the upstream/cherry-picked commit a828eb185aac41800df8eae4b60501ccc0dbbe51. No exact fixed package versions were provided, so use distribution security advisories and kernel changelogs for the affected product line. If immediate patching is not possible, reduce exposure by removing untrusted users from GPU-capable systems, restricting access to /dev/dri/card* and /dev/dri/renderD* device nodes, avoiding GPU device pass-through to untrusted containers, enforcing container device allowlists, and disabling or blacklisting the xe kernel module where the hardware/driver is not required.

How to confirm the fix worked

Confirm the running kernel version with uname -r and compare it against the relevant distribution or vendor advisory for this issue. Validate the installed kernel changelog or source package contains the fix text "drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import()" or commit a828eb185aac41800df8eae4b60501ccc0dbbe51. On source-based or internally built kernels, inspect the Xe dma-buf import error path and confirm dma_buf_detach() is called when xe_dma_buf_init_obj() fails after dma_buf_dynamic_attach(). Also verify runtime exposure by checking whether the xe module is loaded and whether untrusted users or workloads can access /dev/dri devices. After patching, reboot into the fixed kernel and confirm the old vulnerable kernel is not still running.

Typical attack path

1. Gain local execution on a Linux system running an affected kernel with the DRM Xe driver enabled.
2. Confirm access to GPU/DRM device nodes such as /dev/dri/card* or /dev/dri/renderD*.
3. Create or obtain dma-buf file descriptors that can be imported through the Xe GEM PRIME import path.
4. Trigger an import sequence where dma_buf_dynamic_attach() succeeds but xe_dma_buf_init_obj() fails.
5. Repeat the failing import path to accumulate leaked dma-buf attachments or stale kernel references.
6. Use the resulting resource leak or object-lifetime side effects to cause host instability, denial of service, or to support further local kernel exploitation.

How to detect it

There are no reliable public indicators proving exploitation from the provided information. To investigate possible prior abuse, review kernel logs, system journals, audit logs, and EDR telemetry for repeated DRM/Xe driver errors, GPU resets, abnormal dma-buf or PRIME import failures, kernel warnings, OOM events, or crashes initiated by local users or containers with access to /dev/dri. Correlate suspicious events with process execution history, container IDs, user sessions, and device-access audit records. Pay particular attention to repeated failures from the same local process or workload followed by increasing kernel memory pressure, graphics driver instability, or host reboots. If feasible, use auditd or eBPF-based telemetry to identify processes repeatedly opening /dev/dri/card* or /dev/dri/renderD* and issuing DRM ioctls at high volume. Absence of these artifacts does not prove non-exploitation because this bug may not emit a unique log message.

What your security team should do

• Inventory Linux systems with Intel Xe DRM support, loaded xe driver modules, or exposed /dev/dri device nodes.
• Prioritize patching on multi-user systems, GPU-enabled servers, VDI fleets, CI/build runners, and container hosts that pass GPU devices into workloads.
• Upgrade to a vendor kernel containing the Xe dma-buf attachment leak fix, then reboot and verify the fixed kernel is active.
• Restrict /dev/dri/card* and /dev/dri/renderD* access to trusted users and trusted workloads only.
• Review container, Kubernetes, and virtualization configurations for unnecessary GPU device pass-through.
• Where the Xe driver is not required, consider disabling or blacklisting the xe module until a fixed kernel is deployed.
• Monitor kernel logs for repeated DRM/Xe errors, GPU resets, memory pressure, OOM events, or host instability that correlates with local user or container activity.
• Treat exploitation likelihood as currently low due to low EPSS, no KEV listing, and no known exploit maturity, but do not defer remediation on shared local-access systems.