CVE-2026-31440

What it actually does

This is a local Linux kernel availability flaw in the Intel Data Streaming Accelerator / IAA idxd dmaengine driver. During device removal, the driver resets the device before freeing event-log memory. The reset clears configuration registers, so the cleanup path may incorrectly conclude that event-log support was not enabled and skip freeing memory that was previously allocated. A local user with sufficient ability to trigger repeated device remove, unbind, reset, or hotplug-style driver teardown operations can cause kernel memory to leak over time, potentially exhausting memory and degrading or crashing the host. The flaw does not directly provide code execution, privilege escalation, or data disclosure based on the published description.

Why it matters to the business

Systems using affected Linux kernels with idxd-supported accelerator hardware may become unstable or unavailable if the vulnerable driver path is repeatedly exercised. The main operational risk is denial of service: workloads can slow down, fail, or the host can require rebooting after memory exhaustion. The EPSS score is very low, there is no known KEV listing, and no public exploit maturity is reported, so broad opportunistic exploitation is unlikely; however, the impact can still be meaningful for performance-sensitive servers, virtualization hosts, storage nodes, or compute platforms that rely on stable accelerator-enabled Linux kernels.

How an attack unfolds

An attacker first needs local access and privileges sufficient to interact with device management paths for idxd-capable hardware, such as administrative access, delegated device-management permissions, or access to a container or workload configuration that can cause device unbind/remove/reset behavior. The attacker repeatedly triggers the affected device removal or reset sequence. Each time the vulnerable cleanup path runs after the device reset, the driver may fail to free allocated event-log memory because the hardware configuration state has been cleared. Repeating this cycle gradually consumes kernel memory. Once enough memory is leaked, the system may experience allocation failures, service degradation, OOM events, kernel instability, or a denial-of-service condition requiring intervention or reboot.

How to fix it

Upgrade to a Linux kernel version from the distribution or kernel vendor that includes the idxd dmaengine fix for event-log memory cleanup during device removal. Because no exact fixed versions were provided, use vendor advisories and package changelogs to identify kernels containing the patch described as fixing 'dmaengine: idxd: Fix leaking event log memory'. Where immediate patching is not possible, reduce exposure by limiting local administrative/device-management access, restricting access to accelerator devices, disabling or unloading the idxd driver if the hardware is not required, and preventing untrusted workloads from controlling device reset/unbind paths. Any mitigation that disables accelerator functionality should be tested for workload impact before broad deployment.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix by checking distribution security advisories, kernel changelogs, or source patches for the idxd event-log cleanup change. Verify whether the system is exposed by checking for loaded idxd-related modules, idxd-capable devices, and DSA/IAA sysfs entries. After remediation, perform a controlled device remove/unbind/reset test in a non-production environment and confirm that kernel memory does not grow persistently across repeated cycles. Monitor dmesg, kernel logs, and memory metrics for repeated idxd teardown events, increasing unreclaimable kernel memory, OOM activity, or device reset failures.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel with the idxd driver and compatible accelerator hardware present or exposed.
2. Gain or use permissions that allow device reset, unbind, removal, hotplug, or driver-management operations for the idxd device.
3. Trigger the idxd device remove/reset path so the device configuration registers are reset before event-log memory cleanup completes.
4. Repeat the operation to accumulate unreleased kernel memory.
5. Cause memory pressure, service disruption, OOM conditions, or host instability resulting in denial of service.

How to detect it

Detection should focus on signs of prior device lifecycle abuse and memory exhaustion rather than a unique exploit payload, because the vulnerability is a kernel cleanup bug and no public exploit indicators are reported. Review kernel logs, dmesg, journald, audit logs, and EDR telemetry for repeated idxd, DSA, or IAA device reset, remove, bind, or unbind activity followed by rising kernel memory use, OOM-killer activity, service crashes, or host reboots. On systems with auditd enabled, look for writes to sysfs driver bind/unbind controls or commands that unload/reload idxd-related modules. Correlate suspicious activity with local user sessions, privileged containers, automation jobs, or maintenance tooling. Threat hunting should prioritize hosts where idxd hardware is present, the idxd driver is loaded, and unexplained OOM or instability occurred.

• idxd
• intel_idxd
• /sys/bus/dsa/devices/
• /sys/bus/dsa/drivers/idxd/unbind
• /sys/bus/dsa/drivers/idxd/bind
• /sys/bus/dsa/drivers/idxd/
• /dev/dsa/
• modprobe idxd
• rmmod idxd
• modprobe -r idxd
• Out of memory
• oom-killer
• invoked oom-killer
• Kernel panic - not syncing
• dmaengine: idxd
• idxd: reset
• idxd: device reset
• idxd: remove
• idxd: unbind
• DSA
• IAA

What your security team should do

• Inventory Linux systems using kernels that include the idxd dmaengine driver and identify hosts with Intel DSA/IAA accelerator hardware or exposed DSA devices.
• Prioritize patching on shared compute, virtualization, container, database, storage, and high-availability systems where local users or workloads could influence device lifecycle operations.
• Apply the kernel update from the relevant Linux distribution or vendor once available, then reboot into the fixed kernel and remove obsolete vulnerable kernels where operationally feasible.
• Until patched, restrict access to device-management interfaces, sysfs unbind/bind paths, accelerator devices, and administrative capabilities that allow hardware reset or driver unload/reload.
• Disable or blacklist the idxd driver on systems that do not require Intel DSA/IAA functionality, after validating that no workload depends on it.
• Add monitoring for repeated idxd device reset/remove/unbind activity, kernel memory growth, and OOM events on systems where the driver is present.
• Because there is no KEV listing, no ransomware association, and very low EPSS, treat this as a targeted/local availability risk rather than an internet-scale emergency, while still remediating through normal kernel maintenance cycles.