CVE-2026-31441

What it actually does

This vulnerability is a local denial-of-service issue in the Linux kernel Intel Data Streaming Accelerator / idxd DMA engine driver. During reset of an idxd workqueue, the driver can mark the workqueue type as NONE before all associated resources are released. Other driver logic interprets that state as meaning the workqueue is already empty, which can prevent proper cleanup and cause kernel memory to leak. Repeated triggering of the reset path by a local privileged or partially privileged user with access to the affected device interfaces can progressively consume kernel memory, potentially causing system instability, out-of-memory conditions, service degradation, or a crash. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable by exhausting memory. This is most relevant for servers using Intel DSA/idxd acceleration or exposing idxd workqueue management to local users, containers, batch workloads, or service accounts. The likely business impact is service interruption, degraded application performance, failed jobs, node eviction in clustered environments, or unplanned reboot/recovery activity. The vulnerability is not currently listed in CISA KEV, is not associated with ransomware use, has very low EPSS, and has no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, shared compute, HPC, virtualization, and multi-tenant Linux environments should still treat it as a local availability risk.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient permissions to interact with idxd/DSA device configuration or reset paths. They identify that the system has the idxd driver loaded and one or more idxd workqueues configured. The attacker repeatedly triggers workqueue reset or disable/reset operations that reach the vulnerable cleanup path. Because the driver marks the workqueue as empty before its resources are actually released, cleanup can be skipped or incomplete, causing memory to remain allocated. By repeating this action, the attacker accumulates leaked kernel memory until the host experiences memory pressure, out-of-memory killing, degraded workload performance, driver failure, or a system crash/reboot. There is no indication from the provided data that this flaw enables code execution or data theft.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the idxd workqueue reset cleanup bug. Because no fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory once available. Prioritize systems where the idxd driver is loaded, Intel DSA hardware is present, and untrusted or semi-trusted local users can access accelerator configuration interfaces. If immediate patching is not possible, mitigate by disabling unused Intel DSA/idxd functionality, unloading or blacklisting the idxd driver where operationally safe, restricting access to idxd device nodes and sysfs configuration paths, limiting local user access, and monitoring for repeated workqueue resets or memory growth. Rebooting may clear leaked memory temporarily but does not remediate the underlying issue.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the vendor fix for this vulnerability, not just that an updated package is installed on disk. Check the active kernel version after reboot and compare it with the fixed version in the distribution advisory. Validate exposure by checking whether idxd is loaded with commands such as lsmod, modinfo, or sysfs inspection under /sys/bus/dsa and /sys/bus/dsa/devices. Systems without the idxd driver loaded or without Intel DSA/idxd hardware are generally not practically exposed to this specific driver path. After patching, test normal idxd workqueue reset/disable operations in a controlled environment and monitor for stable memory usage, absence of OOM events, and absence of repeated idxd reset errors in kernel logs.

Typical attack path

1. Gain local access to an affected Linux system.
2. Confirm the idxd driver and Intel DSA workqueue interfaces are present and usable.
3. Obtain or use existing low-privileged access capable of triggering idxd workqueue reset or cleanup paths.
4. Repeatedly reset or disable affected idxd workqueues.
5. Cause unreleased kernel resources to accumulate through the vulnerable cleanup ordering bug.
6. Drive the system into memory pressure, OOM events, service disruption, or crash.

How to detect it

Look for signs of prior local denial-of-service attempts rather than remote compromise. Useful sources include kernel logs, systemd journal, audit logs, syslog, dmesg output, endpoint telemetry, and resource monitoring data. Search for repeated idxd, DSA, dmaengine, or workqueue reset/disable activity followed by rising memory usage, OOM killer events, process terminations, driver errors, or unexpected host reboots. Correlate these events with local user sessions, sudo activity, batch jobs, container launches, or scripts that accessed /sys/bus/dsa, /dev/dsa, /dev/idxd, or related accelerator management paths. Because this is a memory leak DoS, there may be no durable artifact after reboot beyond logs and monitoring history. Absence of logs does not prove non-exploitation if kernel ring buffers were overwritten or the host crashed before logs were persisted.

• idxd
• dmaengine
• /sys/bus/dsa
• /sys/bus/dsa/devices
• /dev/dsa
• /dev/idxd
• Out of memory
• oom-killer
• Killed process
• Memory allocation failure
• workqueue reset
• wq reset
• idxd_wq_disable_cleanup
• kernel: idxd
• kernel: dmaengine

What your security team should do

• Inventory Linux systems for loaded idxd/dmaengine drivers and Intel DSA-capable hardware.
• Prioritize patching systems that expose local shell access, shared compute workloads, containers with device access, HPC jobs, or accelerator management permissions.
• Apply the vendor-provided fixed kernel update and reboot into the fixed kernel.
• Where patching is delayed, disable or blacklist idxd if Intel DSA acceleration is not required.
• Restrict permissions to idxd-related device nodes and sysfs configuration interfaces to trusted administrators only.
• Monitor kernel logs for repeated idxd workqueue reset activity, memory pressure, and OOM killer events.
• Add this vulnerability to local availability-risk tracking even though EPSS is very low and it is not in KEV.
• Review change-control and maintenance windows for systems where rebooting into a fixed kernel is required.