CVE-2026-43498

What it actually does

The flaw is a local Linux kernel driver memory/data-corruption issue in the ivpu accelerator DRM path. Imported GEM/DMA-BUF objects could be re-exported through the PRIME handle-to-fd callback. During that re-export, buffer flag settings are lost, causing the device to use an incorrect view of the buffer and potentially perform invalid or unintended memory access. Because the affected code runs in the kernel/driver boundary and controls accelerator-accessible memory, impact can include corruption of accelerator buffers, denial of service, information disclosure, and possible local privilege escalation.

Why it matters to the business

Successful exploitation can allow a local authenticated user or compromised local process to corrupt data handled through Intel VPU/DRM buffer sharing, potentially causing service crashes, incorrect AI/accelerator workload results, sensitive data exposure, or privilege escalation depending on how memory is corrupted. The issue is not known to be exploited in the wild, is not in CISA KEV, and has a low EPSS score, so broad internet-driven exploitation is unlikely; however, systems that expose DRM/VPU devices to untrusted users, desktops, shared workstations, CI runners, GPU/VPU-enabled containers, or multi-tenant compute platforms have higher operational risk.

How an attack unfolds

An attacker first needs local code execution with permission to access the affected Linux DRM/VPU device. They open the relevant /dev/dri device, create or obtain a GEM/DMA-BUF object, import it into the ivpu driver, and then attempt to re-export that imported object through the PRIME handle-to-fd path. In vulnerable kernels, this re-export loses important buffer flag state. The attacker can then use the incorrectly represented buffer in subsequent device operations so that the accelerator accesses memory with the wrong permissions or attributes. The practical outcome may be data corruption, device or kernel instability, disclosure of sensitive memory, or a path toward local privilege escalation depending on memory layout, driver behavior, and workload timing.

How to fix it

Update to a Linux kernel package from the operating system or appliance vendor that includes the fix for the ivpu driver change titled "accel/ivpu: Disallow re-exporting imported GEM objects." No universal upstream fixed version was provided in the input, so use vendor advisories, distro changelogs, or kernel commit backport notes to identify the corrected package for each platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the ivpu driver if Intel VPU acceleration is not required, restricting access to /dev/dri/card* and /dev/dri/renderD* to trusted users only, avoiding passthrough of DRM/VPU devices into untrusted containers or virtualized workloads, and limiting local shell or batch-execution access on systems with the affected hardware and driver enabled.

How to confirm the fix worked

Verify remediation by confirming the running kernel package includes the ivpu fix that rejects re-export of imported GEM objects. Check vendor changelogs, package metadata, or source patches for the custom prime_handle_to_fd callback that returns -EOPNOTSUPP for imported objects. On test systems, run a targeted DRM/ivpu regression test that imports a GEM/DMA-BUF object and attempts to re-export it; the operation should fail rather than create a new file descriptor. Also verify that untrusted users and containers cannot access /dev/dri devices unless explicitly required, and confirm that the ivpu driver is unloaded or disabled where mitigation rather than patching is chosen.

Typical attack path

1. Obtain local code execution as a low-privileged user or through a compromised local workload.
2. Confirm the affected ivpu/DRM device is present and accessible through /dev/dri/card* or /dev/dri/renderD*.
3. Create or obtain a GEM/DMA-BUF buffer and import it into the ivpu driver.
4. Invoke the PRIME handle-to-fd export path on the already imported GEM object.
5. Cause the re-exported buffer to lose its original flag state and be treated with incorrect access attributes.
6. Submit accelerator operations that use the malformed buffer state to trigger data corruption, memory disclosure, a kernel/device crash, or further exploitation.

How to detect it

Look for signs of abnormal local use of the Intel VPU/DRM PRIME buffer-sharing path. Useful sources include kernel logs, systemd-journald, auditd, EDR/eBPF telemetry, container runtime logs, and crash dumps. Investigate repeated access to /dev/dri/card* or /dev/dri/renderD* by untrusted users, sandbox escapes, containers, or unexpected processes, especially if followed by ivpu, DRM, DMA-BUF, IOMMU, page-fault, GPU/VPU reset, kernel oops, or data-corruption messages. If syscall or ioctl tracing is available, look for unusual sequences that import a DMA-BUF/GEM object and then immediately attempt PRIME handle-to-fd export operations against the ivpu device. Because the vulnerability produces memory/data corruption rather than a stable network signature, absence of logs does not prove absence of exploitation; correlate device access, process lineage, user activity, crashes, and anomalous accelerator workload results.

• /dev/dri/renderD
• /dev/dri/card
• ivpu
• intel_vpu
• DMA-BUF
• dma_buf
• GEM
• PRIME_HANDLE_TO_FD
• DRM_IOCTL_PRIME_HANDLE_TO_FD
• DRM_IOCTL_PRIME_FD_TO_HANDLE
• prime_handle_to_fd
• EOPNOTSUPP
• IOMMU fault
• GPU HANG
• VPU reset
• kernel: ivpu
• kernel: drm
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel oops

What your security team should do

• Inventory Linux systems that load the ivpu or Intel VPU DRM driver and identify which expose /dev/dri devices to non-administrative users, containers, CI jobs, or shared workloads.
• Prioritize kernel updates on multi-user systems, accelerator-enabled workstations, container hosts, and compute platforms where untrusted code can access DRM/VPU devices.
• If patching is delayed, remove untrusted access to /dev/dri/*, review group membership such as video/render, and stop passing DRM devices into containers unless strictly required.
• Disable or blacklist the ivpu driver on systems that do not require Intel VPU acceleration.
• Add monitoring for unexpected processes accessing DRM render devices and for kernel logs containing ivpu, DRM, DMA-BUF, IOMMU fault, VPU reset, or kernel oops messages.
• After remediation, confirm the installed kernel contains the vendor backport and that attempts to re-export imported ivpu GEM objects fail with EOPNOTSUPP.