CVE-2026-31436

What it actually does

This is a Linux kernel memory-corruption flaw in the Intel Data Streaming Accelerator / idxd DMA engine driver. A logic error in descriptor abort handling can complete the wrong descriptor during list traversal, which may cause NULL pointer dereferences, double completion of DMA descriptors, descriptor leaks, kernel memory corruption, or kernel crashes. Depending on driver reachability and device exposure, the impact can include denial of service and potentially privilege-impacting kernel behavior, because the failure occurs in kernel space.

Why it matters to the business

Systems running affected Linux kernels with the idxd DMA engine driver enabled may become unstable or crash when the vulnerable descriptor-abort path is triggered. For organizations using Intel DSA/idxd acceleration in high-throughput storage, networking, analytics, virtualization, or data-processing workloads, this can cause service interruption, degraded performance, node reboots, and operational disruption. The CVSS score is critical, but current public exploit maturity is listed as none, EPSS is low and flat over 30 days, and the issue is not listed in CISA KEV, so remediation should be prioritized based on whether affected kernels have idxd-capable hardware and the driver enabled.

How an attack unfolds

An attacker must be able to reach code paths that submit and abort descriptors through the Linux kernel idxd DMA engine driver. In a typical scenario, the attacker first obtains a way to interact with a workload, device interface, or local execution context that can cause idxd descriptor allocation and cancellation. They then trigger timing or state conditions that cause llist_abort_desc() to traverse a descriptor list and complete the wrong descriptor. If successful, the kernel may dereference a NULL pointer, complete the same descriptor twice, leak descriptors, corrupt descriptor state, or crash. Practical exploitation is likely dependent on kernel configuration, availability of Intel DSA/idxd hardware, driver exposure, and whether untrusted users or workloads can influence the DMA engine path.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the idxd driver change that completes the traversal descriptor correctly in llist_abort_desc(). Because no exact fixed package versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution or vendor advisory for CVE-2026-31436. If immediate patching is not possible, reduce exposure by disabling or unloading the idxd driver where not required, disabling Intel DSA/idxd devices in firmware or kernel configuration where feasible, limiting access to workloads that can interact with DMA acceleration interfaces, and scheduling reboot-based kernel updates for affected hosts. Validate that mitigations do not disrupt applications that depend on Intel DSA acceleration.

How to confirm the fix worked

Confirm the running kernel package includes the vendor backport or upstream fix for the idxd dmaengine llist_abort_desc() descriptor completion bug. Check whether the idxd module is present or loaded using standard kernel module and sysfs inspection, and verify whether Intel DSA/idxd devices are exposed under the system device tree. After patching, reboot into the fixed kernel and confirm the active kernel version is the updated one rather than only confirming that a package was installed. Review vendor advisories and changelogs for references to dmaengine, idxd, llist_abort_desc(), descriptor completion, or CVE-2026-31436. Where possible, run regression tests for workloads using Intel DSA/idxd acceleration and monitor kernel logs for absence of new idxd-related Oops, panic, NULL dereference, or descriptor completion errors.

Typical attack path

1. Identify a Linux system running an affected kernel with the idxd DMA engine driver present or loaded.
2. Confirm the system has Intel DSA/idxd-capable hardware or software paths that exercise the idxd driver.
3. Gain access to a local workload, container, VM, or application path capable of causing DMA descriptor submission and abort behavior.
4. Trigger descriptor abort or cancellation sequences repeatedly to reach the vulnerable llist_abort_desc() logic.
5. Cause incorrect descriptor completion, resulting in kernel instability, memory corruption, descriptor leakage, or a crash.
6. Use the resulting kernel fault primarily for denial of service, or attempt further exploitation if reliable corruption primitives are developed.

How to detect it

Look for evidence of exploitation or attempted triggering in kernel and system logs rather than application logs. Relevant sources include journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, hypervisor host logs for guest or host resets, and monitoring alerts for unexpected node reboots. Search for idxd or dmaengine messages near kernel Oops, panic, BUG, WARNING, NULL pointer dereference, use-after-free-like symptoms, general protection faults, call traces referencing llist_abort_desc(), descriptor completion errors, or repeated accelerator-related failures. Also review whether crashes correlate with untrusted workloads, containers, batch jobs, or processes using Intel DSA/idxd acceleration. There are no known public exploit-specific network indicators from the provided information; detection should focus on host telemetry, kernel fault artifacts, and crash correlation.

• llist_abort_desc
• dmaengine
• idxd
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• general protection fault
• Call Trace:
• double completion
• descriptor leak
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /proc/modules
• /sys/bus/dsa/devices
• idxd.ko

What your security team should do

• Inventory Linux systems for affected kernel versions and determine which have Intel DSA/idxd hardware, the idxd driver loaded, or DMA acceleration workloads enabled.
• Prioritize patching systems where idxd is enabled in production, especially shared compute, virtualization, high-availability, storage, networking, or data-processing environments.
• Apply distribution-provided kernel updates that contain the fix and reboot systems into the fixed kernel.
• Temporarily disable or unload the idxd driver on systems that do not require Intel DSA/idxd functionality.
• Restrict untrusted local users, containers, and workloads from accessing accelerator interfaces or device nodes that may exercise the vulnerable path.
• Monitor kernel logs for idxd, dmaengine, NULL pointer dereference, Oops, panic, double completion, descriptor leak, or unexpected reboot events.
• Because public exploit maturity is currently none and EPSS is low, prioritize by actual exposure rather than score alone, but do not defer patching on systems where the driver is reachable.