CVE-2026-43064

What it actually does

This is a local denial-of-service flaw in the Linux kernel idxd dmaengine driver used for Intel DSA/IAA accelerator devices. When a DSA/IAA device object is released, its associated workqueue is not properly released, causing kernel resources to remain allocated after the object is freed. A local user with sufficient access to exercise or reconfigure the affected accelerator device path could repeatedly trigger the faulty release path, leading to resource exhaustion, kernel instability, or system unavailability. The vulnerability does not provide a known path to data disclosure or privilege escalation based on the available description.

Why it matters to the business

Successful exploitation can degrade or crash Linux systems that expose the affected idxd/DSA/IAA functionality, disrupting workloads that depend on those hosts. The practical exposure is narrower than a remote network flaw because exploitation requires local access and relevant device interaction capability. It is not listed in CISA KEV, has very low EPSS, no known mature exploit, and no ransomware association, so urgency is generally lower than internet-facing remote code execution issues; however, systems using Intel accelerator features in production should still be patched during the next appropriate maintenance window because the impact is high availability loss.

How an attack unfolds

An attacker first obtains local access to a Linux system running an affected kernel with the idxd driver active and DSA/IAA hardware or exposed accelerator device interfaces available. The attacker then interacts with the device management or workqueue lifecycle, such as repeatedly creating, enabling, disabling, or removing DSA/IAA workqueues through legitimate local interfaces or tooling. Because the vulnerable kernel code fails to release the workqueue correctly when the associated object is freed, each cycle can leave resources behind. Repetition can accumulate leaked kernel resources until the host becomes unstable, device functionality fails, or the system experiences a denial of service requiring service restart or reboot. There is no indication from the supplied data of public exploit code, remote exploitation, or active threat-actor use.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix for the idxd dmaengine workqueue release bug. No exact fixed package versions were provided in the input, so use vendor advisories and kernel changelogs to identify the first fixed build for each distribution. Where immediate patching is not possible, reduce exposure by disabling or unloading the idxd driver if Intel DSA/IAA acceleration is not required, blocklisting the module where operationally safe, restricting local shell access, limiting access to DSA/IAA device nodes and sysfs configuration paths, and controlling use of accelerator-management tools such as accel-config. Because this is a kernel flaw, application-level mitigations are not sufficient if the vulnerable driver remains reachable.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel build includes the vendor fix for the idxd dmaengine release path, not merely that a patched package is installed but pending reboot. Check the active kernel with uname and vendor package tools, then compare against the distribution advisory or changelog for this issue. Validate whether the vulnerable component is exposed by checking whether the idxd module is loaded and whether DSA/IAA devices are present under sysfs. If the driver was disabled as a mitigation, confirm it is not loaded after reboot and that DSA/IAA device interfaces are unavailable to untrusted users. Avoid destructive reproduction in production; if testing is required, perform it in an isolated system with comparable hardware and confirm repeated workqueue lifecycle operations no longer cause resource growth, driver errors, or kernel instability.

Typical attack path

1. Gain local authenticated access to a Linux host running an affected kernel.
2. Confirm the idxd driver and Intel DSA/IAA accelerator interfaces are present and usable.
3. Use local device-management interfaces or accelerator configuration tooling to exercise DSA/IAA workqueue creation, teardown, or device release paths.
4. Repeat the lifecycle operation to accumulate unreleased kernel workqueue resources.
5. Cause accelerator failure, kernel resource exhaustion, system instability, or host denial of service.

How to detect it

There are no known threat actors, public exploit maturity, KEV listing, or ransomware use indicated for this issue, so detection should focus on signs of local abuse or failed exploitation rather than known malware indicators. Review kernel logs, system journal, audit logs, sudo logs, shell history where available, and endpoint telemetry for repeated interaction with DSA/IAA accelerator management paths, frequent accel-config use, idxd driver errors, resource exhaustion, kernel warnings, and unexpected reboots. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k, auditd records for writes under /sys/bus/dsa/devices/, process execution logs for accel-config or scripts manipulating DSA/IAA workqueues, and EDR telemetry showing module load/unload activity for idxd. Pay particular attention to sequences where a non-administrative or unexpected local account repeatedly enables, disables, configures, or removes DSA/IAA workqueues shortly before memory pressure, kernel faults, driver failures, or host outage. Because resource-leak denial-of-service activity can resemble misconfiguration or stress testing, correlate administrative change tickets, accelerator workload deployment, and maintenance activity before declaring compromise.

• idxd
• dmaengine
• /sys/bus/dsa/devices/
• /sys/bus/dsa/drivers/idxd
• /dev/dsa
• accel-config
• modprobe idxd
• rmmod idxd
• insmod idxd
• idxd:
• dsa
• iaa
• workqueue
• Out of memory
• oom-killer
• kernel panic
• BUG:
• WARNING: CPU
• soft lockup
• hard LOCKUP

What your security team should do

• Inventory Linux systems with Intel DSA/IAA hardware or the idxd kernel module loaded, and prioritize those used for production workloads or shared multi-user access.
• Patch affected systems with vendor kernel updates and ensure hosts are rebooted into the fixed kernel.
• If patching must be delayed, disable or blocklist the idxd driver where DSA/IAA acceleration is not business-critical.
• Restrict local access and permissions to DSA/IAA device management interfaces, including sysfs paths and accelerator configuration tooling.
• Monitor for repeated DSA/IAA workqueue reconfiguration, idxd driver errors, out-of-memory events, kernel warnings, and unexpected reboots.
• Treat this as a moderate-priority availability issue unless new exploit activity, KEV listing, or vendor-specific severity information emerges.