CVE-2026-43395

What it actually does

This is a local availability vulnerability in the Linux kernel Xe DRM graphics driver. A low-privileged local user able to interact with the Xe DRM device can trigger error paths in sync object parsing where partially initialized references are not cleaned up. Repeated triggering can leak kernel references to sync objects, fences, chain fences, or user fences, gradually consuming kernel resources and potentially causing degraded graphics/GPU behavior, resource exhaustion, process failures, or a system denial of service. The flaw does not provide known confidentiality or integrity impact and is not remotely exploitable under the stated CVSS vector.

Why it matters to the business

Systems using affected Linux kernels with the Intel Xe DRM driver exposed to local users or workloads may be vulnerable to local denial of service. In practical terms, a malicious or compromised local account, container workload with access to DRM devices, or untrusted desktop/application workload could destabilize the host, interrupt graphical or GPU-accelerated services, and require service restart or host reboot. The current EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad active exploitation is not currently indicated; however, shared workstations, GPU-enabled compute nodes, VDI hosts, and multi-user Linux systems should still prioritize remediation because the attack requires only local low-privileged access.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a Linux system running an affected kernel with the Xe DRM driver available. The attacker opens a DRM device node, commonly under /dev/dri, and submits crafted Xe DRM synchronization inputs that cause xe_sync_entry_parse() to allocate one or more internal references before intentionally failing a later validation or parse step. In vulnerable kernels, some failure paths return without calling the cleanup routine, leaving those references leaked. By repeating the malformed requests in a loop, the attacker can accumulate leaked kernel resources until the graphics subsystem or the wider host becomes unstable, processes fail, memory pressure increases, or the system requires administrative intervention or reboot. There is no indication from the provided data that this enables privilege escalation, data theft, or remote compromise.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Xe DRM sync cleanup issue, specifically the change that routes parse failure paths through common cleanup and calls xe_sync_entry_cleanup(sync) before returning errors. If vendor fixed package versions are available from the Linux distribution or appliance vendor, apply those exact kernel updates and reboot into the fixed kernel. Where immediate patching is not possible, reduce exposure by restricting untrusted local access to /dev/dri/card* and /dev/dri/renderD* devices, removing unnecessary users from video/render-equivalent groups, avoiding passing DRM devices into untrusted containers, disabling or blacklisting the Xe driver if it is not required, and isolating GPU-capable workloads to trusted users only. Mitigations that restrict DRM access may affect desktop, GPU compute, media, or rendering functionality and should be tested before broad deployment.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is updated to a vendor build containing the fix. Check with uname -a, package-manager kernel inventory, and vendor advisories for the patched kernel build. If building from source, confirm that the Xe DRM code includes the cleanup behavior for xe_sync_entry_parse() failure paths and the upstream commit identified in the advisory lineage. Reboot after kernel installation and ensure the system is no longer running an older affected kernel. Validate exposure reduction by checking permissions and group ownership on /dev/dri/card* and /dev/dri/renderD*, confirming whether untrusted users or containers can access those devices, and confirming whether the xe module is loaded only where required. In test environments, malformed Xe sync parsing should return errors without steadily increasing unreclaimed kernel resources or causing progressive instability.

Typical attack path

1. Gain local access to a Linux system as a low-privileged user or compromise a workload that has access to DRM device nodes.
2. Confirm that the Xe DRM driver is present and accessible through /dev/dri device files.
3. Open the relevant DRM render or card device from user space.
4. Issue crafted Xe DRM synchronization requests that allocate sync-related kernel references and then force a later parse failure.
5. Repeat the malformed request sequence to leak references over time.
6. Exhaust kernel or graphics-driver resources, causing GPU/graphics instability, process failures, degraded host performance, or a local denial of service.

How to detect it

There are no reliable CVE-specific indicators of compromise in the provided information, and exploitation would likely resemble local misuse of the DRM/Xe graphics interface rather than a distinctive network event. To assess possible prior exploitation, review kernel logs, system journals, GPU/DRM driver logs, audit logs, and endpoint telemetry for repeated local access to /dev/dri/card* or /dev/dri/renderD* followed by resource exhaustion, hung tasks, GPU resets, out-of-memory events, or unexplained host instability. Correlate the timing of crashes or resource pressure with processes owned by non-administrative users that repeatedly open DRM device nodes or issue large volumes of DRM ioctls. On systems with auditd or eBPF telemetry, look for high-frequency open/ioctl activity against /dev/dri devices from unusual binaries, temporary directories, user home directories, containers, or newly introduced workloads. Memory-pressure and denial-of-service symptoms alone are not proof of exploitation; confirmation generally requires process-level telemetry showing suspicious repeated DRM interactions on an affected kernel.

What your security team should do

• Inventory Linux systems using affected kernels, prioritizing hosts with Intel Xe graphics, loaded xe DRM modules, /dev/dri exposure, GPU-enabled containers, multi-user access, VDI, desktop fleets, and GPU compute nodes.
• Apply vendor kernel updates that include the Xe DRM sync cleanup fix and reboot systems into the fixed kernel.
• Until patched, restrict untrusted access to DRM device nodes and avoid passing /dev/dri devices into untrusted containers or sandboxed workloads.
• Review local user and group memberships that grant graphics/render device access, especially video, render, or distribution-specific equivalents.
• Monitor for unexplained local denial-of-service symptoms on affected systems, including repeated GPU/DRM errors, memory pressure, hung tasks, and crashes correlated with untrusted user activity.
• Because EPSS is low, the issue is not in KEV, and no mature exploit is reported, prioritize remediation based on local-user risk and GPU exposure rather than emergency internet-facing response.
• Document reboot completion and running-kernel verification, since kernel package installation alone does not remove exposure until the fixed kernel is active.