CVE-2026-64425

What it actually does

This is a Linux kernel race condition in io_uring's io-wq worker handling. When an io_uring work item has dependent linked work, the worker can snapshot the exit state before processing the full linked chain. If io_uring teardown begins after the first linked item starts, later linked items may continue running instead of being cancelled. The practical result is that io_uring exit/cleanup can be delayed significantly and worker activity can continue after teardown has started. Based on the provided description, the most likely impact is local denial of service or resource exhaustion rather than remote code execution or privilege escalation.

Why it matters to the business

Systems that allow untrusted local users, containers, or workloads to use io_uring may be susceptible to deliberate kernel resource exhaustion or prolonged task cleanup, potentially causing service degradation, stuck processes, noisy hosts, or reduced availability. The current exploitation signal is low: EPSS is 0.00177, it is not listed in CISA KEV, ransomware use is not reported, and no public exploit maturity is indicated. However, because this is in the Linux kernel, exposure can be broad across distributions and container hosts once affected kernel versions are identified.

How an attack unfolds

An attacker needs local code execution on a Linux system where io_uring is available. They create an io_uring instance and submit a chain of linked work items designed to run slowly, block, or otherwise keep io-wq workers busy. While the linked chain is being processed, the attacker closes or tears down the ring so that io_uring exit begins. Due to the race, the worker may continue using a stale view of the exit bit for the remaining linked work items, allowing those items to keep running rather than being cancelled. Repeating this pattern can prolong cleanup and consume kernel worker time and system resources, potentially degrading availability for other workloads on the host.

How to fix it

Apply the vendor kernel update that includes the upstream fix to re-check IO_WQ_BIT_EXIT for each linked work item. Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or kernel supplier and reboot into the patched kernel. As temporary risk reduction, restrict untrusted local access to io_uring where operationally feasible. Options may include disabling io_uring through distribution-supported controls, using seccomp profiles to block io_uring_setup/io_uring_enter/io_uring_register for high-risk sandboxed workloads, limiting untrusted shell/container access, and applying resource controls such as cgroups, process limits, and CPU/memory quotas to reduce denial-of-service impact.

How to confirm the fix worked

Confirm the running kernel, not merely the installed package, contains the vendor fix. Validate with uname -a, distribution package metadata, and vendor advisories for the kernel build in use. Ensure hosts have been rebooted into the patched kernel after update. For exposure validation, check whether untrusted workloads can invoke io_uring_setup, io_uring_enter, or io_uring_register; if mitigations are used, confirm seccomp or policy enforcement blocks those syscalls for the intended workloads. Operationally, monitor for abnormal numbers of io-wq workers, tasks stuck in uninterruptible sleep, excessive io_uring usage, or long process teardown times before and after patching.

Typical attack path

1. Gain local ability to execute code on an affected Linux host, container host, or workload environment.
2. Verify that io_uring is enabled and usable by the current process.
3. Create an io_uring instance using io_uring_setup or an equivalent library wrapper.
4. Submit many linked or dependent work items that are slow to complete or block on device/file operations.
5. Trigger ring teardown while the linked work chain is still being processed.
6. Exploit the race window where exit has begun but later linked work items continue without cancellation.
7. Repeat the pattern to increase cleanup latency, worker contention, and resource pressure.

How to detect it

There are no unique public indicators of compromise for this issue from the provided data. Detection should focus on behavioral evidence of attempted local denial of service using io_uring. Review auditd, eBPF, syscall telemetry, EDR, or container runtime logs for unusual bursts of io_uring_setup, io_uring_enter, and io_uring_register from untrusted processes. Correlate those events with process exits, ring/file descriptor closure, spikes in io-wq worker activity, tasks stuck in D state, elevated load average without matching CPU usage, slow container or process teardown, and kernel logs mentioning hung tasks or blocked workers. On container hosts, compare io_uring activity by workload identity and investigate workloads that generate repeated io_uring setup/teardown patterns with many linked operations. If kernel tracing is available, inspect io_uring and io-wq tracepoints around suspected time windows for repeated ring teardown concurrent with pending work. Because the expected exploitation impact is resource exhaustion rather than persistence, absence of malware artifacts does not rule out attempted abuse.

What your security team should do

• Inventory Linux systems, container hosts, and multi-tenant workloads that run kernels with io_uring enabled.
• Prioritize patching systems that allow untrusted local users, CI jobs, containers, or customer-controlled workloads to execute code.
• Deploy the relevant vendor kernel update and reboot systems into the fixed kernel.
• Where immediate patching is not possible, restrict io_uring syscalls for untrusted workloads using seccomp, sandbox policy, or distribution-supported controls.
• Add monitoring for unusual io_uring syscall volume, excessive io-wq worker activity, stuck tasks, and degraded host availability.
• Review container and sandbox profiles to ensure untrusted workloads cannot freely use kernel features that are unnecessary for their function.
• Track distribution advisories for the exact kernel package versions that include the fix, since no fixed versions were provided in the input.
• Treat exploitation likelihood as currently low because it is not KEV-listed, has low EPSS, and has no reported public exploit maturity, but still remediate as part of normal kernel patch cadence due to availability risk.